1067146 - On YouTube and other video sites, the time bar stops moving when you skip through videos.

Status: RESOLVED DUPLICATE of bug 1032992

(Firefox :: Untriaged, defect)

Description

[gumballisthegreatest]

Attachment: YouTube buffering circle.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140911151253

Steps to reproduce:

I have clicked on the bar or pressed the arrow key to go through the video on YouTube.


Actual results:

The gray bar stops moving and the buffering circle appears. Later on, I get "An error occurred. Please try again later."


Expected results:

The gray bar should have continued moving like it would on previous Firefox versions, Google Chrome, Opera, Safari and Internet Explorer.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

1) Please don't spam random people in bugs. I've removed everyone from the CC because as far as I can tell that's what happened. If you file the bug in the right component, people will already be notified automatically. Even if you file in general, volunteers will sort the bug in the right component for you.
2) Problems which are only reported when they are already in a released version are very hard to fix in time for a next version because there is little time to test them properly. If you want to avoid this, please help us by running a Beta or earlier (Aurora, Nightly) and reporting problems early.
3) You should probably clarify whether you are running Flash, what exact version of Flash you are using, and whether YouTube is using Flash or HTML5 to render video. This is needed to see if the problem is in Firefox, Flash or YouTube.
4a) Is this a regression in Firefox 32.0.1 as compared to Firefox 32.0?
4b) Does this problem ocurr in Beta/Aurora/Nightly?
4c) Are you sure this is not caused by the recent update of Adobe Flash to 15.0?

Comment 2

[gumballisthegreatest]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)
> 1) Please don't spam random people in bugs. I've removed everyone from the
> CC because as far as I can tell that's what happened. If you file the bug in
> the right component, people will already be notified automatically. Even if
> you file in general, volunteers will sort the bug in the right component for
> you.
> 2) Problems which are only reported when they are already in a released
> version are very hard to fix in time for a next version because there is
> little time to test them properly. If you want to avoid this, please help us
> by running a Beta or earlier (Aurora, Nightly) and reporting problems early.
> 3) You should probably clarify whether you are running Flash, what exact
> version of Flash you are using, and whether YouTube is using Flash or HTML5
> to render video. This is needed to see if the problem is in Firefox, Flash
> or YouTube.
> 4a) Is this a regression in Firefox 32.0.1 as compared to Firefox 32.0?
> 4b) Does this problem ocurr in Beta/Aurora/Nightly?
> 4c) Are you sure this is not caused by the recent update of Adobe Flash to
> 15.0?

1. I am not spamming
2. I think they should fix this.
3. I think this is a problem with Firefox
4a. Yes it is
4b. I didn't use it.
4c. No it's not.

Comment 3

[Matthias Versen [:Matti]]

(In reply to gumballisthegreatest from comment #2)
> 1. I am not spamming

You spammed already twice with this single bug report.
You added several people to the CC list without asking or knowing the people and you changed the component back to Firefox:general but everyone that knows the bug database only a little bit knows that this can't be a Firefox:general bug.

> 2. I think they should fix this.
Firefox is an open source browser and we are accepting a patch from you that fixes this bugs.

> 3. I think this is a problem with Firefox
What do you think doesn't matter in this case because Gian-Carlo asks for something that only you can answer (unless someone else can reproduce the issue) and that is a simple technical fact.
In case you don't know how to check that you can ask and we can help you.

> 4a. Yes it is
You are sure that you previously didn't have Firefox31 installed ?

> 4b. I didn't use it.
A developer can only fix bugs that he can either reproduce and which are bugs in our code (and not in Flash or youtube) or if a developer gets enough information (logs, regression range down to the checkin,..) to identify the bug. 
Providing more information can be a little work for a reporter (like you) but is necessary. Without that help we can not fix the bug and we can just close this report. 

> 4c. No it's not.
You answer is based on which fact ?

Comment 4

[gumballisthegreatest]

(In reply to Matthias Versen [:Matti] from comment #3)
> (In reply to gumballisthegreatest from comment #2)
> > 1. I am not spamming
> 
> You spammed already twice with this single bug report.
> You added several people to the CC list without asking or knowing the people
> and you changed the component back to Firefox:general but everyone that
> knows the bug database only a little bit knows that this can't be a
> Firefox:general bug.
> 
> > 2. I think they should fix this.
> Firefox is an open source browser and we are accepting a patch from you that
> fixes this bugs.
> 
> > 3. I think this is a problem with Firefox
> What do you think doesn't matter in this case because Gian-Carlo asks for
> something that only you can answer (unless someone else can reproduce the
> issue) and that is a simple technical fact.
> In case you don't know how to check that you can ask and we can help you.
> 
> > 4a. Yes it is
> You are sure that you previously didn't have Firefox31 installed ?
> 
> > 4b. I didn't use it.
> A developer can only fix bugs that he can either reproduce and which are
> bugs in our code (and not in Flash or youtube) or if a developer gets enough
> information (logs, regression range down to the checkin,..) to identify the
> bug. 
> Providing more information can be a little work for a reporter (like you)
> but is necessary. Without that help we can not fix the bug and we can just
> close this report. 
> 
> > 4c. No it's not.
> You answer is based on which fact ?

1. I have now downgraded to 31 and it works fine.

2. *bug

3. I am using Flash 15 and I am only having this problem when using 32.

4a. I had Firefox 31 in the summer time and didn't have any of these problems. I have downgraded back to 31.

4b. I don't use Beta, Aurora or Nightly

4c. It's not a problem with Flash 15, it's a problem with Firefox 32. I hope this gets fixed for Firefox 33.

Comment 6

[Jim Mathies [:jimm]]

I'm not able to reproduce this, can we get exact steps to reproduce the bug?

Comment 7

[Jim Mathies [:jimm]]

Gerv, we're running into a minor bugzilla abuse problem here. 

1) ccing random people into bugs (cbeard, for example)
2) filing multiple bugs for the same issue
3) marking core-security, then remarking after core-sec people clear the flag.
4) generally refusing to work with engineers in diagnosing the issue.

Comment 8

[Gervase Markham [:gerv]]

gumball: your issue is unlikely to be fixed unless you make a good-faith effort to do (or not do) what people have asked you to. We will do our best to help you, but remember you got Firefox for free, and no-one is _obligated_ to look at your bug reports.

Gerv

Comment 9

[gumballisthegreatest]

(In reply to Gervase Markham [:gerv] from comment #8)
> gumball: your issue is unlikely to be fixed unless you make a good-faith
> effort to do (or not do) what people have asked you to. We will do our best
> to help you, but remember you got Firefox for free, and no-one is
> _obligated_ to look at your bug reports.
> 
> Gerv

This issue happens with Firefox 32, but not 31. This really needs to be fixed for Firefox 33.

Comment 10

[Gervase Markham [:gerv]]

Saying "you need to fix it" is not very helpful. If it were simple, it would be done already. It would be better to answer some of the technical questions that people have asked you.

Gerv

Comment 11

[gumballisthegreatest]

(In reply to Gervase Markham [:gerv] from comment #10)
> Saying "you need to fix it" is not very helpful. If it were simple, it would
> be done already. It would be better to answer some of the technical
> questions that people have asked you.
> 
> Gerv

OK Gerv, I have answered some of the questions that people have asked me. Can you have this fixed for the upcoming Firefox 33?

Comment 12

[Gervase Markham [:gerv]]

(In reply to gumballisthegreatest from comment #11)
> OK Gerv, I have answered some of the questions that people have asked me.
> Can you have this fixed for the upcoming Firefox 33?

As far as I can see, no-one else can reproduce this problem. We can't fix what we can't see.

Are you sure Flash is still being used in Firefox 33? I heard that YouTube had switched to using their HTML5 player in some cases. Can you give a URL to a video where you see this happen? If you right-click on the video, do you get a Flash menu or an HTML5 menu?

Gerv

Comment 13

[Chris Peterson [:cpeterson]]

gumballisthegreatest: with the following steps, you can share details about your Firefox configuration that may be useful for Firefox developers trying to debug the problem:

1. Click Firefox's Help menu > Troubleshooting Information
2. In the new "about:support" tab, click the "Copy text to clipboard" button
3. Paste that information into this bug report.

Comment 14

[Jim Mathies [:jimm]]

FWIW, did some more testing this morning with fx 31 and 32:

http://www.youtube.com/watch?v=-YkLPxQp_y0

Flash 15.0 r0NPSWF32_15_0_0_152.dll

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

No issues. Maybe be an addon issue? Have you tried testing in safe mode?

https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode?redirectlocale=en-US&redirectslug=Safe+Mode

Comment 15

[gumballisthegreatest]

(In reply to Jim Mathies [:jimm] from comment #14)
> FWIW, did some more testing this morning with fx 31 and 32:
> 
> http://www.youtube.com/watch?v=-YkLPxQp_y0
> 
> Flash 15.0 r0NPSWF32_15_0_0_152.dll
> 
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
> 
> No issues. Maybe be an addon issue? Have you tried testing in safe mode?
> 
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode?redirectlocale=en-US&redirectslug=Safe+Mode

I always use the skip thing and the gray bar stops on Firefox 32, but not on 31. Safe mode will not help. It's like saying that Sonic and Tails exist in real life, which they don't. I think it's an issue with Firefox 32 and 32.0.1.

Comment 16

[gumballisthegreatest]

(In reply to Gervase Markham [:gerv] from comment #12)
> (In reply to gumballisthegreatest from comment #11)
> > OK Gerv, I have answered some of the questions that people have asked me.
> > Can you have this fixed for the upcoming Firefox 33?
> 
> As far as I can see, no-one else can reproduce this problem. We can't fix
> what we can't see.
> 
> Are you sure Flash is still being used in Firefox 33? I heard that YouTube
> had switched to using their HTML5 player in some cases. Can you give a URL
> to a video where you see this happen? If you right-click on the video, do
> you get a Flash menu or an HTML5 menu?
> 
> Gerv

Maybe I'll be using 31 until the release to Firefox 33. In my honest opinion, HTML5 is better than Flash player because you won't have to deal with this "Shockwave Flash may be busy" message on YouTube videos anymore.

Comment 17

[gumballisthegreatest]

I tested this problem on Firefox 32.0.3 and the time bar getting stuck problem on Firefox Flash videos still persists. If a Firefox 32.0.4 ever comes out, can Chris Beard and other Mozilla employees investigate on this problem so they can fix it?

Comment 18

[strobe]

Hi gerv, cpeterson, jimm, thanks so much for investigating this issue.

YouTube is currently tracking an increase in complaints similar to those described by the OP. We've got analytics that show the issue is tied to the release of Firefox 32.0.1 in the field. Our analytics show that Flash playbacks are, after a certain point, not placing any requests that reach our servers. 

Affected playbacks seem to involve at least one request that got cancelled from the Flash side partway through reading the request due to a format change (due to e.g. bandwidth change, manual quality selection, or going fullscreen). The YouTube Flash player attempts to make use of disk cache by aligning its range= query-param requests to the same blocks, meaning that a cancelled connection has a chance to be restarted later on. The decision to send this cancellation happens in the process of evaluating queued events, so there may be some network transfer data sitting in the system which the Flash runtime hasn't passed on to the player (or the player hasn't processed) by the time the decision to cancel for an adaptation is made.

Our view of the Flash client isn't complete, so I can't confirm this with certainty, but it's my hunch that the issue occurs as a result of a race condition between request cancellation from within the Flash plugin and request completion from within the cache layer. It's possible that this configuration can end up leaving the request in a zombie state, where Firefox uses the presence of a cached entry to decide to serve the request from disk cache, but doesn't follow through on actually delivering those bytes (or perhaps a completion event?) to the plugin.

All of this is hypothetical, but it fits better than any other theory we've got so far. Repro depends on conditions that trigger a cancelled and restarted request, which while common enough to make us start this investigation, may not be common enough to enable repro for most developers.

We'll continue to investigate this from our side. I'm happy to answer any additional questions you might have.

Thanks for looking into this!

Comment 19

[Jim Mathies [:jimm]]

It'd be great if we could get a regression range from someone who can reproduce.

Comment 20

[Gervase Markham [:gerv]]

strobe: when you say this is tied to 32.0.1, does that mean that you are fairly sure that it doesn't occur with 32.0.0?

jmathies/bsmedberg: who's the right person to look at this?

Gerv

Comment 21

[crschmidt]

gerv: (Also from YouTube) -- we don't track browser version below the second dot, so we only have 32.0 in our logs to easily analyze. (Initially, I didn't realize there had been a 32.0.0; https://www.mozilla.org/en-US/firefox/32.0.0/releasenotes/ being a 404 threw me off.) We do, however, see a spike in percentage of playbacks which have this problem starting on 9/2, correlating with the 32.0.0 release (and a larger spike with 32.0.1, but that might just be volume.)

Looking through more specifically: it appears that from the 2nd (the first day we have enough volume to make a reasonable guess), the rate of this problem on FF 32 has not changed meaningfully, so it seems like FF32.0.0 is equally affected.

It appears that this problem has been occurring at approximately the same rate (out of playbacks on Firefox 32) since at least August 20th. (~25% higher rates before release; this may be consistent with beta customers more likely to have whatever the trigger condition for this race condition is, whether it be some extension or other behavior on YT.)

Comment 22

[Jim Mathies [:jimm]]

ni'ing juanb, we should investigate good str and try to find a regression range, this is going to be tough to track down otherwise.

Comment 23

[crschmidt]

Okay, I've gone back further in time: It looks like this has been an issue since May. The rate of stopped playbacks (our primary signal for this problem) increased on May 3rd; it looks like it went back to 'normal' (10x lower) on the 8th/9th, then returned to a higher rate on May 18th, where it has stayed ever since. 

The most compelling looking change (from reviewing forum posts on Moz forums) seems to be the caching layer changes in FF 32; I'd see if those dates correlate with any significant shifts around the caching layer that would roll out to people running FF32 in May.

Comment 24

[Jim Mathies [:jimm]]

milan, this sounds graphics related.

Comment 25

[crschmidt]

We do not currently have reason to believe this is graphics related. Some evidence that supports the notion of caching:

 - At least two users reporting this bug have reported that setting browser.disk.cache.enable to false causes the buggy behavior to stop. (https://support.mozilla.org/en-US/questions/1018552, https://support.mozilla.org/en-US/questions/1019116)
 - The reason playback stops is that the player has no more data, consistent with believing it has sent a request and never getting a response back; graphics issues generally manifest in different ways.

While I'm not ruling it out entirely, this is most likely cache or network related, and not graphics related, based on the data I have seen so far.

Comment 26

[Benjamin Smedberg]

I highly doubt this is graphics-related. I've seen something like this also; mcmanus, are there NSPR logging settings or other tools I could use to diagnose this, assuming it's cache-related?

Comment 27

[Patrick McManus [:mcmanus]]

honza is point man on all things cache

Comment 28

[Honza Bambas (:mayhemer)]

Sure:

NSPR_LOG_MODULES=timestamp,cache2:5,nsHttp:4

Comment 29

[gumballisthegreatest]

Firefox 33 is expected to come out soon. I really hope this problem gets fixed for the new version.

Comment 30

[Larry]

Can confirm this is an issue for me all the time on 32.0.0 ("32.0" in About Firefox).

Can't say if it started with 32 as I was on 28 or something before and an older version of Flash.

Comment 31

[juan becerra [:juanb]]

I have been trying to reproduce this problem on a Win8.1 machine with the latest Flash player using nightly builds for Fx32, and I haven't been able to reproduce this problem consistently. It's a little fuzzy, but I think I notice I am able to reproduce the problem more often with builds later than 5/30.

There are a few factors at play: the nightly build, the specific video, the network, and the way the user could be skipping during playback.

Using a nightly from 6/04, latest Flash, and this video: http://www.youtube.com/watch?v=eHEIElnsoiM I notice the following when:

1. Load the link
2. Skip the Ad and then skip to a time around the 3 minute mark
3. Using the arrow keys, left and right, go back a few clicks and go forward a few more

Some times the gray bar that displays the loading progress stops moving, and once the red bar displaying playback progress reaches that point the buffering circle appears and it get stuck there. Some times you will get the "An error occurred. Please try again later." Some times I get a different error message with a blue background explaining that I am having problems and a link to find out why which leads to a Google page explaining that the problem might be due to my ISP.

There was at least one change to the http networking code around 4/28 - 6/04, but that could be just a red herring for lack of anything obvious.

Comment 32

[Jim Mathies [:jimm]]

[Tracking Requested - why for this release]:
based on QA / user feedback, this may affect 32 and up.

Comment 33

[Sylvestre Ledru [:Sylvestre]]

This is too late for 33 (especially without patch) but we will be happy for take a patch for 34.

Comment 34

[Lawrence Mandel [:lmandel] (use needinfo)]

Sounds like our working assumption is that this is cache related.

honza, bsmedberg - What are our next steps on this?

Comment 35

[Lawrence Mandel [:lmandel] (use needinfo)]

To clarify my previous question in comment 34, do we need further investigation to prove this is or is not cache related?

Honza - If we're confident that this is cache related, can you take this bug?

Comment 36

[Patrick McManus [:mcmanus]]

fyi we're honza is out of office last week and this week.. maybe :michal can help (he also worked on the cache code)

Comment 37

[Benjamin Smedberg]

I can still reproduce in my normal profile, but can't in a clean test profile. Are there prefs I may have set in my main profile which could affect this? I do have network.http.spdy.enabled.http2draft;false from previous twitter weirdness.

I appear to be using the non-Flash player.

Comment 38

[Patrick McManus [:mcmanus]]

see also 1083922 which is another case where an old profile with cache1 data in it seems to impact cache2.. michal has agreed to have a look

Comment 39

[Alice0775 White]

Attachment: http log

Here http log, I can reproduce on Firefox32 and Flash player 15.0.0.189.

https://hg.mozilla.org/releases/mozilla-release/rev/c88f138e4b4e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140923175406

Str
1. set NSPR_LOG_MODULES=timestamp,cache2:5,nsHttp:4 
2. Run Firefox (about 20:27:30)
3. Open http://www.youtube.com/watch?v=eHEIElnsoiM
4. Move seekbar by mouse random back/forward 
5. Around 20:28:00-05, this problem happens
6. I wait for 3minitus (around 20:31:00).
7. I quit browser

Comment 40

[willsmcgarnigle]

Seems to be related to this bug; https://bugzilla.mozilla.org/show_bug.cgi?id=810629

Let's see if we can work together to solve this carefully. The bug exists as far as I've upgraded to Firefox release build 29 (with the inception of Australis). Look at the details at the link I've provided. I've tried to depurate the script and found a few jscript errots. Beta Build 34.0b3 v. 4.42.0.0 just after updating today. Further details in there.

Comment 41

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Patrick McManus [:mcmanus] from comment #38)
> see also 1083922 which is another case where an old profile with cache1 data
> in it seems to impact cache2.. michal has agreed to have a look

michal - Are you taking this one?

Comment 42

[Michal Novotny [:michal]]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #41)
> michal - Are you taking this one?

Yes, I'll take it.

Comment 43

[Honza Bambas (:mayhemer)]

Michal took this, so probably no need for info from me anymore.

Comment 44

[Jim Mathies [:jimm]]

This might be related - view this music video (html5 video) and just let it run. At around ~45 seconds to a minute, youtube's player will display a small in frame ad. The connection throbber pops here and we never recover.

http://www.youtube.com/watch?v=VHrLPs3_1Fs

Comment 45

[Michal Novotny [:michal]]

(In reply to Alice0775 White from comment #39)
> Created attachment 8508993 [details]
> http log
> 
> Here http log, I can reproduce on Firefox32 and Flash player 15.0.0.189.


The problem is that the channel opens the cache entry as a reader and waits for the data, but nobody is going to fill the entry. It happens for the audio stream for range 2899968-3141631, the whole URL is http://r16---sn-3pm7ened.googlevideo.com/videoplayback?c=web&clen=16856913&cpn=XdiPlCej4PJGSmNU&cver=as3&dur=1049.982&expire=1413944855&fexp=910207%2C914020%2C917000%2C924619%2C927622%2C930666%2C930672%2C931983%2C932404%2C934030%2C936106%2C945528%2C947209%2C949008%2C949417%2C951701%2C952302&gir=yes&id=o-AMogWD-jrR9A5rLeHQ7WgcbNOC8bAc6y2NhELHU8Hchb&initcwndbps=6067500&ip=220.12.66.186&ipbits=0&itag=140&keepalive=yes&key=yt5&lmt=1399188972688257&mime=audio%2Fmp4&mm=31&ms=au&mt=1413923183&mv=m&range=2899968-3141631&ratebypass=yes&signature=4B5FD1D8F04FE192F45EFED3FA29470631E4AB46.E44BF4925E6C879017055EA5260914F82BF42A2F&source=youtube&sparams=clen%2Cdur%2Cgir%2Cid%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Ckeepalive%2Clmt%2Cmime%2Cmm%2Cms%2Cmv%2Csource%2Cupn%2Cexpire&sver=3&upn=F2ztAXrANkE


Honza, could you please have a look at it? You know this part of the cache code much better. Here is a summary describing what happens:

First channel that is opened for this URL is a08f800 (time 20:27:58.491000). Other relevant pointers are:
  nsHttpTransaction c575000
  CacheEntry        c9406a0
  CacheEntryHandle  9e5e510
  CacheFile         11fb0880

nsHttpTransaction receives 11680 bytes of data and then the connection is closed. nsHttpChannel::OnDataAvailable() is never called and no output stream is opened.

Later, a second channel c575000 (time 20:27:58.830000) is created, the situation is wrongly interpreted as concurrent read/write and input stream is opened. Yet later, another three channels (ce3e800, 7372c00, abae000) are opened and all end up waiting for the data.

Comment 46

[Honza Bambas (:mayhemer)]

I think this is a duplicate of bug 1032992 that landed on 33 (we wanted to be safe).  Apparently on 32 the patch is not present:

http://hg.mozilla.org/releases/mozilla-release/file/c88f138e4b4e/netwerk/cache2/CacheEntry.cpp#l792


The reason the channel fails is that OnStartRequest callback returns a failure.


[:sylvestre] - this has never been confirmed in 33+, why exactly have you raised the flags?

Comment 47

[Sylvestre Ledru [:Sylvestre]]

Because of comment #32

Comment 48

[Honza Bambas (:mayhemer)]

(In reply to Jim Mathies [:jimm] from comment #32)
> [Tracking Requested - why for this release]:
> based on QA / user feedback, this may affect 32 and up.

This is not a confirmation.  Who ever said this was a problem on 33+?  Please confirm, thanks.

Comment 49

[Sylvestre Ledru [:Sylvestre]]

I don't know. I just relied on Jim's request for tracking.
Jim, did you had some other information?

Comment 50

[Jim Mathies [:jimm]]

the assumption was if its on 32 its on 33 and up. if that's not the case, obviously it doesn't need to track those releases.