Closed
Bug 1364476
Opened 5 years ago
Closed 5 years ago
Pandora stream not playing correctly
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
platform-rel | --- | ? |
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | verified |
firefox56 | --- | fixed |
People
(Reporter: marcia, Assigned: cpearce)
References
Details
(Keywords: regression, Whiteboard: [platform-rel-Pandora][webcompat])
Using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0 ID:20170511063838 CSet: 838652a84b76c273e084d0705f3f4f3be89520a8 STR: 1. Open https://www.pandora.com/station/play/3000031766228716931 2. Listen to the stream. Eventually the stream gets messed up and it sounds as if I have 2 audio sources playing.
Updated•5 years ago
|
Flags: needinfo?(jyavenard)
Comment 1•5 years ago
|
||
This is using Flash, not much we can do about it...
Flags: needinfo?(jyavenard)
Comment 2•5 years ago
|
||
Pandora uses HTML5 now at least there's an <audio> element on the page.
Comment 3•5 years ago
|
||
the page won't load without flash... so hard to say
Updated•5 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-Pandora]
Comment 4•5 years ago
|
||
I went into add ons and disabled the Adobe Shockwave Flash plugin and Pandora doesn't display anything saying it requires Flash. Is there any additional steps? I was going to just fire up a virtual machine and install Nightly on it as a way to confirm. I don't really want to do that unless it's necessary.
Comment 5•5 years ago
|
||
I can reproduce this in current Nightlies. At some point you end up with more than one <audio> element playing the same track, and they can build up if you hit skip. Unfortunately mozregression gave a pretty big range between 54 and 55, but I believe this is a regression. 49:19.44 INFO: Switching bisection method to taskcluster 49:19.44 INFO: Getting mozilla-central builds between 0b255199db9d6a6f189b89b7906f99155bde3726 and 37a5b7f6f101df2eb292b1b6baaf1540c9920e20 49:23.02 WARNING: Skipping build 37a5b7f6f101: unable to find a build url for the changeset u'37a5b7f6f101df2eb292b1b6baaf1540c9920e20' 49:24.62 WARNING: Skipping build 17d8a1e278a9: unable to find a build url for the changeset u'17d8a1e278a9c54a6fdda9d390abce4077e55b20' 49:24.82 WARNING: Skipping build c3e5497cff1c: unable to find a build url for the changeset u'c3e5497cff1c995821b1c9320fa71f1ef9a8c30e' 49:25.04 WARNING: Skipping build 22aaf8bad4df: unable to find a build url for the changeset u'22aaf8bad4df8e5f8c976f1521c213cb37e2dff5' 49:26.42 WARNING: Skipping build 81977c96c6ff: unable to find a build url for the changeset u'81977c96c6ff49e4b70f88a55f38d47f5e54a08b' 49:26.44 WARNING: Skipping build 1fda52a1f3b8: unable to find a build url for the changeset u'1fda52a1f3b81cf1a821155998dca637bb64e3d9' 49:26.98 WARNING: Skipping build 38f862749aed: unable to find a build url for the changeset u'38f862749aed4e9a874182a9019e0671289088b0' 49:28.29 WARNING: Skipping build b21b974d60d3: unable to find a build url for the changeset u'b21b974d60d3075ae24f6fb1bae75d0f122f28fc' 49:28.30 WARNING: Skipping build e0955584782e: unable to find a build url for the changeset u'e0955584782e6eb13bb1e7b197d3064660bb756f' 49:28.66 WARNING: Skipping build bab7046ee2d8: unable to find a build url for the changeset u'bab7046ee2d82345d7d5b33b8ae4009c7e365176' 49:30.06 WARNING: Skipping build ec15663c6331: unable to find a build url for the changeset u'ec15663c6331c8227d458bce85e6ca1b37423336' 49:30.26 WARNING: Skipping build b0ff0c5c0a35: unable to find a build url for the changeset u'b0ff0c5c0a35a1ee9f19cec2bae5cc2cd5772db6' 49:30.43 WARNING: Skipping build d715ee055ae7: unable to find a build url for the changeset u'd715ee055ae7d09acf790e40b6742c5241c7501e' 49:32.29 INFO: Expanding higher limit of the range to b9bd73036a92 49:33.65 WARNING: Skipping build e7bf9443be2c: unable to find a build url for the changeset u'e7bf9443be2c4a5187c37440e35f3526148d7fa8' 49:35.08 WARNING: Skipping build 23fe0b76a018: unable to find a build url for the changeset u'23fe0b76a018a5077a0f7234cff91c41e4b6af64' 49:36.54 WARNING: Skipping build ff83fde8be94: unable to find a build url for the changeset u'ff83fde8be946eabcf27ea97d4676f601c122194' 49:37.92 WARNING: Skipping build 9348b76977e8: unable to find a build url for the changeset u'9348b76977e833f108cf77dff75b0fab887a2fc1' 49:40.10 WARNING: Skipping build c273884ffe6b: unable to find a build url for the changeset u'c273884ffe6bb255399bb15fbad6eb0b66be49eb' 49:41.46 WARNING: Skipping build 8872ad4d52b6: unable to find a build url for the changeset u'8872ad4d52b6b517dc9d2a9f62c5c75ceda18790' 49:41.48 INFO: No more inbound revisions, bisection finished. 49:41.48 INFO: Last good revision: 0b255199db9d6a6f189b89b7906f99155bde3726 49:41.48 INFO: First bad revision: b9bd73036a925e44f44ee87e779fbbdb2dbe618c 49:41.48 INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b255199db9d6a6f189b89b7906f99155bde3726&tochange=b9bd73036a925e44f44ee87e779fbbdb2dbe618c
Keywords: regression
Comment 6•5 years ago
|
||
it is my understanding the Pandora only very recently moved to HTML5 from Flash. it would be good to know from Pandora under which circumstance do they create a new audio element (and why they don't keep reusing the same one)
Reporter | ||
Comment 7•5 years ago
|
||
ni on :dees to see if we have a contact at Pandora that might be able to answer Comment 6.
Flags: needinfo?(dchinniah)
Comment 8•5 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #6) > it would be good to know from Pandora under which circumstance do they > create a new audio element (and why they don't keep reusing the same one) This doesn't answer the "why", but it shows that it's at least intentional: <audio preload="auto" id="mediaelement_1" src="https://t3-1.p-cdn.com/access/?version=5&lid=1883785137&token=H%2FW27gOIQ5F%2B6mjWzeeHKGj8SliaSl9dLYuByVHF2ugCwIKUGJKbeQ6Xw5trGkyaSSmtdWjZYdlI7BaEyk3bamv5JoeVtDP4yDId3kPAlyWysaEtfcPXoKPtYrBe6rJYAXT2EtRLy3rFaxQAjC7xg6XdOnek%2Benh5Vzz95dJGOPC3Epzu1viv4BlG6tYTc8f42GSSx7GLyFM1ePN8v%2BgU3iDh1IltmekNoi3TInvZQ%2Bcu0mw4bUDWtKzBI99S6ZYwDcxBdi0d5IgQ5Hpr3JDK8RHUk5dBP5H05hMZhR1DPxZvln2bpRptD5yktiexlhLof2BUdxx9%2BcUaf0tKAZT2A%3D%3D" data-reuse-elements="disabled"></audio> Each new audio element has a data-reuse-elements="disabled" attribute. https://gist.github.com/miketaylr/52696a79a1c95d200c20bee2863e4df2#file-gistfile2-txt-L1 has the method that's creating and inserting the elements into the DOM, but I haven't gotten the when/why yet.
Comment 9•5 years ago
|
||
(giving up for now, new debugger in nightly has bugs :( https://github.com/devtools-html/debugger.html/issues/2782#issuecomment-303234237)
Comment 10•5 years ago
|
||
One other thing, the moment we get the duplicate audio element, we xhr a POST to https://www.pandora.com/api/v1/station/playbackResumed. So why the phantom resuming a non-paused media element...
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/6860
Comment 12•5 years ago
|
||
¡Hola! This is not OS X specific. I see it... err hear it on Firefox 55.0a1 20170530030204 on Win10 as well. Another thing that happens is that once there are two streams playing, no amount of pausing or muting the tab makes the second stream go away. ¡Gracias! Alex
OS: Mac OS X → All
Hardware: Unspecified → All
(In reply to Marcia Knous [:marcia - use ni] from comment #7) > ni on :dees to see if we have a contact at Pandora that might be able to > answer Comment 6. We have a mailing list (same syntax as others) with the Pandora folks. I'm not sure if either :jya :adamopenweb or :miketaylr have already reached out using this channel?
Flags: needinfo?(miket)
Flags: needinfo?(jyavenard)
Flags: needinfo?(dchinniah)
Flags: needinfo?(astevenson)
Comment 14•5 years ago
|
||
We're not ready for outreach yet, IMO. Last week I was in Norway where I couldn't keep working on diagnosis, hopefully will have enough time this week.
Flags: needinfo?(miket)
Flags: needinfo?(jyavenard)
Flags: needinfo?(astevenson)
Comment 16•5 years ago
|
||
Not yet, but I'll keep at it (I've been caught up in all sorts of diagnosis-work, but tomorrow I'll devote all my time to this one).
Flags: needinfo?(twisniewski)
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7341
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7417
Comment 17•5 years ago
|
||
I think I've found the culprit, though it's difficult to parse what's actually causing it. It seems to be being caused by Pandora's client-side scripts making requests with HTTP Range headers that go past the end of the song. Here's some background. Sometimes during a song's playback an error of some sort happens, and the "We are experiencing trouble playing audio" message appears. It seems to recover sometimes, only logging a message to the console: ERROR Client/actions/Stats: Stats API call failed This seems to be triggered by a MutationCallback that's in turn triggered by a setTimeout. A call is made to drainQueues, a promise is ultimately rejected somewhere, handled by a settlePromiseFromHandler method, and that's that. However, sometimes things don't recover as nicely. The same message appears, similar code appears to happen, but instead of doing the above a GET request is made to a server's "access" endpoint (ie https://audio-sv5-t1-2-v4v6.pandora.com/access/). However, the response to that request is a 400/Bad Request. This is then followed by an XMLHttpRequest POST to "playbackResumed" (ie https://www.pandora.com/api/v1/station/playbackResumed). Then a "new Audio" context is created, and we end up with the current song playing twice (one in the old context, one in the new, slightly out of sync). When each context finishes playing the song, they both begin playing a completely new song. And the problem can repeat for each, from what I can tell. Here's the Curl-equivalent of one request which triggers the 400 response: curl 'https://audio-dc6-t1-1-v4v6.pandora.com/access/?version=5&lid=1634790290&token=N2kpXRRCIgR4GqcxGRmEZHajPi73PHmVbmO1bQdVRp3Ivj1A6QjRJPFT%2BFcudGGz3MzFbprc1l7yGBQDs2ftY%2BYqfpRV2W%2FqcirPXdHQRm2StbNPHdHXAF46y9kgr9NgrCokobBKFciY%2BWPLQvSoHorLBpx3%2FAKEngowqpyFYVEai0xbnw0LGMJf5I5LvG3AVkXrVklyVjwkAWvd6CU27EpO%2BFi5SWftlGKn0QsTdKEcUl2WJX5bmwBqfQh88ImNetezqvuqxck0YaeZDRX0LZraSHKkLQjj2PfKTNUMF2RRnFUVV6yMh6gecjMlINSfAzxySMqsVzc%3D' -H 'Host: audio-dc6-t1-1-v4v6.pandora.com' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0' -H 'Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5' -H 'Accept-Language: en-US,en;q=0.5' -H 'Referer: https://www.pandora.com/station/play/3614121393881410450' -H 'Range: bytes=1196447-' -H 'Cookie: v2regbstage=true; at=w+4JR9QV/A586fLmbTRHODb2DtdNLz3iv9lfyPmlr8BZYBBuTkOUMfuVQGVqrgZtZ06p8aU9GI2MvP4oVCACHyL5o7cJLN5i/; v3ad=1:0:0:00000::0:0:0:0:::::0:0:0:0:0:1; pwc-2016=true; csrftoken=166fc33ba9dc1f13; _sl_path=/station/play/3614121393881410450' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' And here is a similar Curl version of one which is fine: curl 'https://audio-ch1-t1-2-v4v6.pandora.com/access/?version=5&lid=1634790290&token=baj4XMjHcK6Lq4eiHSI%2FDOqfXT%2Bkr3uSZ4S2UrcjPoio5J%2B2c6tDDU68kX0pNXYGaTjOTUQd%2Bf2V02IROUJEKdT9Ny17JEUHoz%2FJNnKQ7HpFuTVYrkOu8hNfsIcIs7D6igZzpandnuziF9kPwzMNQKaeNJudc9ue4%2F5iuEZ4jlt4iXjfzJN0DeN6cmg%2Fv%2F4x3I6U7g7D7L83MuUr4PSjjKdUnLzNm8PlwgBWxhhWUtamV6rqiBdOO4i9mNYaTA3iVujJ8PLUniNIxE%2Bk1129hRPWH3KV88c1EcIQ94sSnTiscb4LUSIG2eD6rFtoSaUSufPhBihr%2BKU%3D' -H 'Host: audio-ch1-t1-2-v4v6.pandora.com' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0' -H 'Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5' -H 'Accept-Language: en-US,en;q=0.5' -H 'Referer: https://www.pandora.com/station/play/3614121393881410450' -H 'Range: bytes=0-' -H 'Cookie: v2regbstage=true; at=w+4JR9QV/A586fLmbTRHODb2DtdNLz3iv9lfyPmlr8BZYBBuTkOUMfuVQGVqrgZtZ06p8aU9GI2MvP4oVCACHyL5o7cJLN5i/; v3ad=1:0:0:00000::0:0:0:0:::::0:0:0:0:0:1; pwc-2016=true; csrftoken=a89d062674f6a593; _sl_path=/station/play/3614121393881410450' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' The bad request works when I change the Range value to "1196446-" instead (one byte less), indicating that it may be an off-by-one issue, or something similar. Likewise, changing the Range on the "good" request to a large enough value triggers the same 400 response. But it's tough to gauge what the scripts are doing to make the requests out-of-range, or why the error handling isn't stopping playback of the existing Audio context before starting a new one in this case. Mike, do you think this would be enough for outreach?
Flags: needinfo?(miket)
Comment 18•5 years ago
|
||
Thanks Thomas! Dragana, comment #17, does anything jump out at you that's HTTP/network related from the mozregression range that might be related: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b255199db9d6a6f189b89b7906f99155bde3726&tochange=b9bd73036a925e44f44ee87e779fbbdb2dbe618c
Flags: needinfo?(miket) → needinfo?(dd.mozilla)
Comment 19•5 years ago
|
||
I just did a by-ear regression range narrowing and got this result: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b255199db9d6a6f189b89b7906f99155bde3726&tochange=37a5b7f6f101df2eb292b1b6baaf1540c9920e20 Unfortunately it couldn't find any build urls for the changesets in that range :(
Comment 20•5 years ago
|
||
I am experiencing the same problems with Pandora on the Nightly browser. Man am I glad I found you guys. I thought I might be alone on this one.
Comment 21•5 years ago
|
||
(In reply to Mike Taylor [:miketaylr] (55 Regression Engineering Owner) from comment #18) > Thanks Thomas! > > Dragana, comment #17, does anything jump out at you that's HTTP/network > related from the mozregression range that might be related: > > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=0b255199db9d6a6f189b89b7906f99155bde3726&tochange=b9bd > 73036a925e44f44ee87e779fbbdb2dbe618c This does not look like a networking problem. Can you make a http log, so I can see what is happeing in necko? https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging and use MOZ_LOG=timestamp,nsHttp:5
Flags: needinfo?(dd.mozilla)
Comment 23•5 years ago
|
||
Sure. I managed to get a log, but it's 6 megs (even zipped). Here's a link to it on my own server: http://thomas.tanrei.ca/moz/network-log.zip Note that it's near the end of the log that the bug manifested and the song started playing twice, when the console reported accesses to: GET https://ml314.com/imsync.ashx GET https://audio-sv5-t1-2-v4v6.pandora.com/access/ [HTTP/1.1 400 Bad Request 427ms] GET https://ml314.com/imsync.ashx
Flags: needinfo?(twisniewski)
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7492
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7486
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7533
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7536
Comment 24•5 years ago
|
||
(In reply to Thomas Wisniewski from comment #23) > Sure. I managed to get a log, but it's 6 megs (even zipped). Here's a link > to it on my own server: http://thomas.tanrei.ca/moz/network-log.zip > > Note that it's near the end of the log that the bug manifested and the song > started playing twice, when the console reported accesses to: > > GET https://ml314.com/imsync.ashx > GET https://audio-sv5-t1-2-v4v6.pandora.com/access/ [HTTP/1.1 400 Bad > Request 427ms] > GET https://ml314.com/imsync.ashx thanks for the log. Something outside necko is setting this header. I do not know who. The first request returns: 2017-06-14 15:58:45.092277 UTC - [Socket Thread]: I/nsHttp HTTP/1.1 206 Partial Content 2017-06-14 15:58:45.092278 UTC - [Socket Thread]: I/nsHttp Date: Wed, 14 Jun 2017 15:58:45 GMT 2017-06-14 15:58:45.092329 UTC - [Socket Thread]: I/nsHttp Server: Apache 2017-06-14 15:58:45.092332 UTC - [Socket Thread]: I/nsHttp Content-Range: bytes 0-2071208/2071209 2017-06-14 15:58:45.092334 UTC - [Socket Thread]: I/nsHttp Content-Length: 2071209 ... which is actually the whole resource (Content-Range: bytes 0-2071208/2071209 the last number is size of the resource) Something outside necko makes a new request and sets header Range: bytes=2071209-
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7574
Comment 25•5 years ago
|
||
Interestingly, I can't reproduce this anymore on today's nightly (and neither could Mike Taylor). However, I can still reproduce it with a build from a couple weeks ago, so I did a mozregression to try to find what might have fixed it. Unfortunately it didn't isolate the fix, and I'm not sure what in the range (if anything) would be the likely fix: >No more inbound revisions, bisection finished. >First good revision: 228504fdc6e9e3daea55c61ccd13cff1a8469ec6 >Last bad revision: 416c3c8c4b3db9ba96a103ce7820c9a140a3051d >Pushlog: >https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=416c3c8c4b3db9ba96a103ce7820c9a140a3051d&tochange=228504fdc6e9e3daea55c61ccd13cff1a8469ec6 > >************* Switching to autoland by process of elimination (no branch detected in commit message) >Getting autoland builds between 2cf23132f3b1aba5ed6cfcd2b9cdaabb5cccc0f5 and 228504fdc6e9e3daea55c61ccd13cff1a8469ec6 >ERROR: The url u'https://hg.mozilla.org/integration/autoland/json-pushes?fromchange=228504fdc6e9e3daea55c61ccd13cff1a8469ec6&tochange=2cf23132f3b1aba5ed6cfcd2b9cdaabb5cccc0f5' contains no pushlog. Maybe use another range ? Dragana, might anything in that range stand out as being related to this issue?
Flags: needinfo?(dd.mozilla)
![]() |
||
Comment 26•5 years ago
|
||
I can confirm that this is fixed for me in Nightly! I was running a Nightly that had a pending update. Before doing the update I tested Pandora and I reproduced the bug. I then triggered the update and I can no longer reproduce the bug. Here are the revisions from about:buildconfig: Bad: https://hg.mozilla.org/mozilla-central/rev/95543bdc59bd038a3d5d084b85a4fec493c349ee Good: https://hg.mozilla.org/mozilla-central/rev/7a6baa6cca3292e8099e652b64d27e74df560874 This gives the following regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=95543bdc59bd038a3d5d084b85a4fec493c349ee&tochange=7a6baa6cca3292e8099e652b64d27e74df560874
Comment 27•5 years ago
|
||
(In reply to Thomas Wisniewski from comment #25) > >************* Switching to autoland by process of elimination (no branch detected in commit message) > >Getting autoland builds between 2cf23132f3b1aba5ed6cfcd2b9cdaabb5cccc0f5 and 228504fdc6e9e3daea55c61ccd13cff1a8469ec6 > >ERROR: The url u'https://hg.mozilla.org/integration/autoland/json-pushes?fromchange=228504fdc6e9e3daea55c61ccd13cff1a8469ec6&tochange=2cf23132f3b1aba5ed6cfcd2b9cdaabb5cccc0f5' contains no pushlog. Maybe use another range ? No pushlog in this range because the tochange was landed earlier than the fromchange in autoland, which is in different order from mozilla-central. If the regression is within this range, let's reverse the two revisions and explicitly asking mozregression to use autoland repo? $ mozregression --repo autoland --find-fix -b 2cf23132f3b1aba5ed6cfcd2b9cdaabb5cccc0f5 -g 228504fdc6e9e3daea55c61ccd13cff1a8469ec6
Comment 28•5 years ago
|
||
According to the regression range in comment 19 and the fixed range in comment 26, bug 1319111 is in both of them. Not sure if it's related.
Comment 29•5 years ago
|
||
With :swu's great tip in comment 27 (thanks!), I got this result: >INFO: First good revision: d1adec83acac5da5f6037a88a13d83eec1b88980 >INFO: Last bad revision: f4a46277935b2702c2a0351204233adb9d7bb3df >INFO: Pushlog: >https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f4a46277935b2702c2a0351204233adb9d7bb3df&tochange=d1adec83acac5da5f6037a88a13d83eec1b88980 That is, bug 1374475. But I'm tired now, so I'll try an m-c build with that patch reverted tomorrow :)
Updated•5 years ago
|
Comment 30•5 years ago
|
||
Note that the issue in bug 1373618, is the server reporting Range-Request at first, yet fail when we seek. Is Pandora having the same issue? It should be fixed in bug 1374475, but only if the MP3 file is less than 8MB in size. The issue will occur for bigger file if the server incorrectly reports capabilities.
Comment 31•5 years ago
|
||
Bug 1374475 is a work around this problem. If the file on Pandora would be bigger or we change our Media-Cache-Size the problem will appear again. in dom/media/MediaResource.cpp we are setting up a new channel and setting request headers as well. Somewhere there we should add a check so that we do not request data that is out of range for a resource (in comment 24 the size of the resource was 2071209 and then we request range '2071209-'). Having two streams playing sounds like a bug probably in MediaResource.cpp Can someone familiar with this code take a look, we should fix this properly?
Flags: needinfo?(dd.mozilla)
Comment 32•5 years ago
|
||
(In reply to Dragana Damjanovic [:dragana] from comment #31) > Having two streams playing sounds like a bug probably in MediaResource.cpp Which 2 steams do you mean?
Comment 33•5 years ago
|
||
(In reply to Dragana Damjanovic [:dragana] from comment #31) > Bug 1374475 is a work around this problem. If the file on Pandora would be > bigger or we change our Media-Cache-Size the problem will appear again. only if Pandora server reports support for range request, but actually does not. > > in dom/media/MediaResource.cpp we are setting up a new channel and setting > request headers as well. Somewhere there we should add a check so that we do > not request data that is out of range for a resource (in comment 24 the size > of the resource was 2071209 and then we request range '2071209-'). > > Having two streams playing sounds like a bug probably in MediaResource.cpp > > Can someone familiar with this code take a look, we should fix this properly? It's not a bug of MediaResource per say. We download up to 30s of data ahead of currentTime. After which the download is suspended. When download is resumed, it can either continue as-is, or it needs to seek where it stopped (but only if seeking was reported as supported by the server, otherwise it redownload from 0). The issue occurs when seeking was reported as supported, yet when we attempt to do so, it doesn't. This is then treated as EOS.
Comment 34•5 years ago
|
||
For the record, I just confirmed that commenting out the code from the patch in bug 1374475 does indeed cause the problem to manifest. There is also a debug message in stdout that I had missed before which pops up when the error happens: >[Child 75097] WARNING: Decoder=11b887800 state=SEEKING Audio not synced after seek, maybe a poorly muxed file?: file dom/media/MediaDecoderStateMachine.cpp, line 1375 However, :jya, their server does support Range requests (I just double-checked). It just returns a 400 response when the range is from past the end of the file, which is what Firefox seems to end up sending, as per comment 17.
Comment 35•5 years ago
|
||
Hmmm... I can see why. We can't rely on the MediaResource's length as it typically changes over time, in particular live streaming... The MP3Demuxer reads until it fails and then treats it at as EOS.... why would that start another stream however... we aren't the one starting a 2nd audio stream, pandora must be handling some particular events thinking it's all done, when it's not.
Flags: needinfo?(jwwang)
Comment 36•5 years ago
|
||
(In reply to Thomas Wisniewski from comment #34) > debug message in stdout that I had missed before which pops up when the > error happens: > > >[Child 75097] WARNING: Decoder=11b887800 state=SEEKING Audio not synced after seek, maybe a poorly muxed file?: file dom/media/MediaDecoderStateMachine.cpp, line 1375 > This is irrelevant for an audio only file. There's no A/V sync to worry about. It only means that when we seek to currentTime=t ; we end up slightly ahead of t , which isn't surprising as seeking in an MP3 is a highly estimated affairs.
Comment 37•5 years ago
|
||
(In reply to Thomas Wisniewski from comment #34) > However, :jya, their server does support Range requests (I just > double-checked). It just returns a 400 response when the range is from past > the end of the file, which is what Firefox seems to end up sending, as per > comment 17. Requesting past the range request should be okay (as I wrote, typically the Content-Length is a moving target on many server). Does it ignore completely the request and return 400, or return at least all the data from the beginning of the range to the existing length? if not the latter, that IMHO is the wrong behaviour on this server.
Comment 38•5 years ago
|
||
It gives a 400 if you request a range that starts past the end of the file, or the range is nonsensical. These requests work (for a file that's under 100000000 bytes long): Range: bytes=0- Range: bytes=0-100000000 Range: bytes=1000-100000000 These do not work, they give a 400 response: Range: bytes=10000000- Range: bytes=10000000-10000001 Range: bytes=2000-1000
Comment 39•5 years ago
|
||
but what about 1000-200000000?
Comment 40•5 years ago
|
||
Yes that works fine, like the third case I listed above.
![]() |
||
Comment 41•5 years ago
|
||
(In reply to Nicholas Nethercote [:njn] from comment #26) > I can confirm that this is fixed for me in Nightly! Actually, I just hit it again. But that was after listening for a couple of hours. It's certainly happening *much* less frequently.
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/7769
Updated•5 years ago
|
Priority: -- → P1
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/8001
Updated•5 years ago
|
See Also: → https://webcompat.com/issues/8086
Comment 42•5 years ago
|
||
Can't repro the issue on Mac. It says "Please ensure you are using the latest Flash Player". Can't repro the issue on Linux either where audio elements are used.
Flags: needinfo?(jwwang)
Assignee | ||
Comment 43•5 years ago
|
||
I hit this issue yesterday, and I think my Nightly was up-to-date enough to include the fix for bug 1373618. I will try again today with a fully update Nightly and logging enabled. The patch in bug 1373618 should make us not request after the end of the resource when recovering from suspending the download. We shouldn't be suspending the download if the Content-Length is less than 8MB now that bug 1374475 is in Nightly. Ideally, the server should respond with a 416 response when we request after the end of the resource.
Comment 44•5 years ago
|
||
Just listened for 1.5 hours and didn't hit the bug, but we've had a few recent webcompat reports so it's still out there for some people it seems.
Assignee | ||
Comment 45•5 years ago
|
||
I've been listening for several multi-hour sessions and I haven't hit the bug again. So bug 1374475 may have fixed or worked around it.
Updated•5 years ago
|
Whiteboard: [platform-rel-Pandora] → [platform-rel-Pandora][webcompat]
Updated•5 years ago
|
Flags: qe-verify+
Comment 46•5 years ago
|
||
Per comment 45, let's have QA to verify on 55.
Reporter | ||
Comment 47•5 years ago
|
||
ni on Andrei for verification since we are getting close to the end of the 55 cycle.
Flags: needinfo?(andrei.vaida)
(In reply to Marcia Knous [:marcia - use ni] from comment #47) > ni on Andrei for verification since we are getting close to the end of the > 55 cycle. Hi, I reproduced this issue on Nightly 55.0a1 (2017-05-12) using STR from comment 0. This is not reproducible anymore on 55.0b11 (20170720101430) using Windows 10 x64 and Mac OS X 10.11.5. I had some issues, unfortunately with my VPN proxy on Ubuntu 16.04 (I've used VPN - Hola due to country restrictions), the pandora's website didn't load every time, or when it eventually loaded, it took up to 10 minutes. So, I cannot properly verify and confirm if this issue is fixed or not on Ubuntu. Please let me know if I can help with more info!
Flags: needinfo?(andrei.vaida)
Comment 49•5 years ago
|
||
Ciprian, Thanks for your testing. Mike, Can someone in your team living in USA help test it on Ubuntu and see if those web compat issues are gone as well?
Flags: needinfo?(miket)
Comment 50•5 years ago
|
||
Sure thing, I'll fire up Ubuntu now and see if I can reproduce there.
Flags: needinfo?(miket)
Comment 51•5 years ago
|
||
Adam Stevenson just verified that the issue appears to be fixed in Nightly on Ubuntu. So... let's close as FIXED. (If there's reasons for it to stay open, apologies, just re-open).
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
status-firefox54:
--- → unaffected
status-firefox56:
--- → fixed
status-firefox-esr52:
--- → unaffected
I will mark this as verified fixed per comment 48 and comment 51.
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•