New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 46 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

html5 audio fails to load (hits max simultaneous connections per server:proxy)

Reported by w...@storytellingmachines.com, Nov 26 2012

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11

Steps to reproduce the problem:
1. Clear cache (if you've visited the link before).
2. Go to url (tab1).
3. Refresh the page a few times.
4. Open new tab (tab2) to the same url.
5. Refresh tab1.

What is the expected behavior?
At step 2, 3 and 4 you should see all html5 audio files available to be played.

What went wrong?
Step 2 results in only having 6 audio files ready to play (see step2.png).

At Step 3, after a few refreshes, the two repeated songs ("Makin' it Happen" and "Pucker Up") are the only ones that cannot be played (see step3.png).

At step 4, all of the audios on tab2 cannot be played (see step4.png). Hitting refresh on tab1 causes the audios to be loaded on tab2 but then not loaded on tab1.

Example URL:
http://stmtest.s3-website-us-east-1.amazonaws.com/chrome_audio_bug.html

Did this work before? No 

Chrome version: 23.0.1271.64  Channel: stable
OS Version: OS X 10.7.4

This definitely looks like a max connections issue. Oddly both firefox (16.0.2) and safari (5.1.6) work fine despite having the same max connection of 6.

Also tested with 25.0.1330.0 canary with identical results.
 
step2.png
34.1 KB View Download
step3.png
32.9 KB View Download
step4.png
21.7 KB View Download

Comment 1 Deleted

It was pointed out that it could be that Chrome is behaving correctly while safari and firefox are not respecting the 6 max connection rule. I've ran this test on the three browsers with each of their network inspectors (see attached files).

In firefox_net.png, we can see only 6 connections happening simultaneously (note how the top 6 start times all align and only after one finishes does another start). Firefox is reporting very small file sizes (possibly just downloading header info and the first pieces of the song).

In safari_net.png, we can see two clusters of 6 gray dots. First the top 6 gray dots happen and then a little while latter the next 6. Safari is reporting 0 bytes downloaded (not sure what that is about).

In chrome_net.png, we see many more requests than the others but only 6 are active, all others are pending. Chrome is also reporting much larger amounts downloaded (~2.10MB for each file).

So it appears each browser is indeed respecting the max of 6 connections. Safari and firefox must be downloading less upfront and somehow freeing up the connections (I also just tried clicking play on all of the songs as fast as possible and firefox and safari were both able to play them simultaneously just fine).
chrome_net.png
187 KB View Download
firefox_net.png
138 KB View Download
safari_net.png
87.0 KB View Download
Labels: WebKit-Audio

Comment 4 by crogers@google.com, Nov 27 2012

Cc: scherkus@chromium.org
Labels: -OS-Mac OS-All Feature-Media-Network
Hrm. This appears to be caused by the decision to defer the network connection for media resources after it reaches a threshold (you'll notice the buffering bar doesn't go the whole way when loading).

You'll notice if you play one clip that after it finishes loading it'll free up a connection.

Network gang: I wonder whether deferred connections should count towards the limit :\
Status: Untriaged
When you say deferred connections, you mean our connection request queue that begins queueing once we hit 6 connections per host in the network stack, right? Or is the media resource loader doing some other kind of deferring?

The network stack isn't aware of what type of content is being requested, it mostly just understands that it's HTTP. It's nice to keep it that way and not bypass limits unless absolutely necessary. What do you think about doing something similar to Firefox or Safari? Once we decide to stop reading/buffering, release the connection, so it can be used for another request (it's kind of unfortunate that we have to fully close the connection to cancel it, but oh well. In SPDY it'd just be a stream reset). And if we play the media, then issue a HTTP range request for the remaining data. Thoughts?
Deferred as in WebURLLoader::setDefersLoading(bool)
http://trac.webkit.org/browser/trunk/Source/Platform/chromium/public/WebURLLoader.h

...which I believe is implemented by queueing IPCs and messages containing network data until all queues are full at which point the network stack keeps the connection open but stops reading data off the socket.

Something like you describe would/could work. I'm sure it'd break some other cases but worth thinking about :)

Comment 9 by k...@google.com, Dec 10 2012

Owner: willchan@chromium.org
Status: Assigned
Will, can you take this?  
Cc: -scherkus@chromium.org willchan@chromium.org
Owner: scherkus@chromium.org
Hot potato! I'm passing the buck to scherkus for the media folks, unless he wants to say it's a networking issue we should fix. I'm going to suggest that the network stack not fix this, since we are respecting the 6 connections per host limit like all other browsers. If they're freeing up connections to rotate among different media resources, we might want to do the same.
Labels: Mstone-26
Owner: ----
Status: Available
Yeah this is definitely ours to figure out. There's a whole mini-project for someone on our team to rethink + tweak our connection / loading strategy.

That being said, I don't think this is something that has a trivial fix. Moving to M26 as available and I'll see if I can find an owner.
Project Member

Comment 12 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Internals-Network -WebKit-Audio -Feature-Media-Network -Mstone-26 M-26 Cr-Internals-Media-Network Cr-Internals-Network Cr-Content-Audio
Labels: -M-26 M-28 MovedFrom-M26
Bulk edit: Moving non-release blocking bugs to M28.
Project Member

Comment 14 by bugdroid1@chromium.org, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 15 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Audio Cr-Blink-Audio
Project Member

Comment 16 by bugdroid1@chromium.org, May 8 2013

Labels: -M-28 MovedFrom-28
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 17 by tsay...@gmail.com, Apr 10 2014

Since nothing has happened on this in over a year, should we expect that this will not get fixed?

If so does any know of a decent work around? [Server side or client side?]

Comment 18 by tsay...@gmail.com, May 18 2014

Looks like it might be fixed in the Chrome I recently installed (Version 34.0.1847.132).  Does anyone know if the fix has made it into chromium and if so at what version?

Comment 19 by Deleted ...@, Jul 28 2014

This is still an issue in Version 36.0.1985.125
Cc: jgraettinger@chromium.org mmenke@chromium.org ranjitkan@chromium.org acolwell@chromium.org
 Issue 401845  has been merged into this issue.
What's the likelihood that this will get fixed soon?  Its disappointing that this has been around for so long.  And that Chrome behaves differently than other browsers.  We users aren't concerned about why, just that its an issue that impacts our browsing when using Chrome.

Comment 22 by peter@chromium.org, Sep 25 2014

 Issue 416936  has been merged into this issue.

Comment 23 by tsay...@gmail.com, Oct 16 2014

This may have been fixed for a while this summer. But the issue still exists in Chrome Version 37.0.2062.120 (64-bit).

This issue is still occurring in the latest release: Version 39.0.2171.65 m (64-bit)

When will this be fixed?  Viewers of my site using chrome are getting annoyed with this issues and there is nothing I can do about it?
 Issue 467681  has been merged into this issue.
Cc: dalecur...@chromium.org
 Issue 448312  has been merged into this issue.
This issue is still occurring in Version 41.0.2272.89 (64-bit).  Whats the hold up on getting this resolved?
Cc: a...@chromium.org
 Issue 468930  has been merged into this issue.
 Issue 453633  has been merged into this issue.
Labels: -Via-Wizard -MovedFrom-M26 -Cr-Blink-Audio -MovedFrom-28
I have fix coming for the preload=metadata case, https://codereview.chromium.org/1029763002/
Awesome Dale, thanks. Is any fix in the works for preload=auto? (as demo'd in my  bug 467681 , merged into this, at this link: http://lacinato.com/pub/bugs/chrome/audio/chromebug.html )
I was about to say no, but I think my fix might actually work there too... I'll have to do some testing and get back to you.
Any idea when this fix will be push to a public/beta release of Chrome?  I don't really want to download the files and compile it.  Thanks for your hard work and time on getting this fixed.
Ideally these changes will be present in M43 which should be available on beta in the next several weeks.

As for preload=auto... unfortunately, there doesn't appear to be a simple way to fix the preload=auto case with our current architecture. The cache miss is too expensive on low bandwidth connections and there's no easy way to gracefully restart the connection preemptively before running out of data. :(

E.g., previously a user with a slow connection and preload=auto would be able to play through in cases where the forward capacity was sufficient, but now they'll hang once the cache capacity is exhausted while we try to catch up.

I'll see about fixing up the cache architecture in the coming months to handle these cases and more in a proper fashion.
Thanks Dale! -- the attention to it is much appreciated.

For those of us that don't quite follow: I'm confused about the preload=auto case -- if the code is caching data for a given file, why does it stop downloading rather than just finish the job? Meaning, in the demo page I posted, it loads about 75-90% of six files (actually, i just re-tested on Linux and it only grabbed a few bytes, but the point stands), and then it pauses all those downloads, presumably because the user hasn't actually started playing any of the files and it doesn't want to waste bandwidth (?), but there is no need to stop the download, yeah? (I suppose there is some good reason HTML5 didn't specify a "preload=yesjustdownloadallofitdarnit", but I wish they had.)

I have no idea about the architecture under the hood, so forgive me if this is ridiculous, but naively its seems like it could just say "if there are remaining media elements on the page that aren't ready to play that have preload=auto, then don't stop downloading data for the 6 i'm downloading now, even if our normal algorithm would have me pause the download." Or more nuanced: for N remaining players needing data, only pause the download for max(6-N,0).

Anyway, sorry, I know how it is when clueless people armchair-code, but I was just curious. :-) And maybe this is the kind of thing you're talking about doing in the coming months.
To save on memory usage preload=auto doesn't download the whole file, only what's necessary to ensure a smooth playback experience for even bandwidth constrained users (if possible, that is).

If you're a web developer and want to workaround this, you can use the Media Source Extensions APIs to fully buffer the file and control playback more carefully. You can also just use an XHR to load the entire media clip into a blob URL and then assign that as the src to the video tag.

In the future we'll do something more intelligent like you're suggesting, where we'll download up to a limit and keep that data cached while closing the connection. We'll also preemptively restart connections as we exhaust the cached data. It's just a harder change and the current code for doing this is very old and crufty, so we'd rather nuke it for something fresher which resolves this and other issues across mobile and desktop platforms.
Makes sense. Thanks for the info and the tips!
Project Member

Comment 38 by bugdroid1@chromium.org, Mar 27 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/849cf4b2ae0cd74c9f618b0950fee69f075de492

commit 849cf4b2ae0cd74c9f618b0950fee69f075de492
Author: dalecurtis <dalecurtis@chromium.org>
Date: Fri Mar 27 18:35:45 2015

Introduce CancelUponDeferral() to buffered media loaders.

Fixes hitting the maximum connection limit of 6 per domain when a
media tag is used with preload=metadata.

Deferred network connections will be cancelled once reaching the
HAVE_ENOUGH_DATA state for preload=metadata, non-streaming
resources that have not started playback.

A soft cancel is introduced which allows us to preserve the data
cached thus far in the BufferedResourceLoader. Once this cache is
exhausted the loader will fulfill subsequent reads with a cache
miss and continue on as normal.

preload=metadata intentionally does not cache enough data for a
smooth playback experience on slow connections, so the cache miss
here does not increase jank relative to the current status quo.

For similar reasons, since preload=auto does load enough data for
an uninterrupted playback, we can't use this method there or we'll
introduce jank during the cache miss and subsequent catch up.

Note: This does not resolve hung connections if multiple media
elements are actually playing back or if they are served from
a server without range requests.

Note 2: This also fixes a broken media_blink_unittests, which was
missing some Gin dependency.

BUG=162627
TEST=new unittest, passes layout tests.

Review URL: https://codereview.chromium.org/1029763002

Cr-Commit-Position: refs/heads/master@{#322610}

[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/BUILD.gn
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/DEPS
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_data_source.cc
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_data_source.h
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_data_source_unittest.cc
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_resource_loader.cc
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_resource_loader.h
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/buffered_resource_loader_unittest.cc
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/media_blink.gyp
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/run_all_unittests.cc
[modify] http://crrev.com/849cf4b2ae0cd74c9f618b0950fee69f075de492/media/blink/webmediaplayer_impl.cc

Comment 39 by b...@chromium.org, Apr 16 2015

Owner: b...@chromium.org
Cc: -willchan@chromium.org
I am using Version 43.0.2357.81 (64-bit), and the bug appears to be fixed on my reported sites.
Metadata is preloaded (showing the size of the audio clip), and any of the audio files can be played, without relying on workarounds.

Thank you!
I am using Version 43.0.2357.81 (64-bit), and the bug still is not fixed for me.  I am still getting the error message at the button saying, "Waiting for available socket..."
 Issue 504219  has been merged into this issue.
Labels: StaleAvailable
This bug has been stale for > 6 month.
If it is not valuable to keep, please resolve it appropriately and add label StaleClosed. 
If it is worth to keep, please replace StaleAssigned label to StaleKeep.
Thanks
Components: -Blink
This bug is still occurring for me on the latest version of: 49.0.2623.87 (64-bit)

I have been hoping this bug would be resolved for a long time, but it is still occurring...please get it fixed.

Thanks,
Same here. This bug is occurring after updating to the latest version: 49.0.2623.87

Our web app needs to preload the metadata for 7 audio files -- but it now fails to load the 7th audio file, thereby crashing our web app.

I'd be greatful to hear of any workarounds / suggestions, if anyone is aware of one.

Labels: -StaleAvailable StaleKeep
Status: Assigned (was: Available)
This bug is ALSO still occurring for me on the latest version of: "49.0.2623.87 m" (64-bit).

I am unable to browse imgur.com for more than, say, 15 minutes before images stop loading. I've encountered *similar* behavior in the past, but blasting-out the sockets area of net-internals would fix it. That now has apparently no effect, however.
This issue only affects stream video and audio.  It does not affect images.  If you're having images with imgur (Which I assume only has images), it's another issues.  Assuming the issue you're running into does not involve video or audio (either paused or playing), please file a new bug, including the net-internals log.  If you tell me the bug id, I'll take a look at it.
 Issue 610149  has been merged into this issue.

Comment 52 by teo8...@gmail.com, May 9 2016

2012? You must be kidding me
Will this issue ever be fixed? It has been an issues for almost 4 years now or longer.  It is still broken in  51.0.2704.103 (64-bit)
Still broken in 60.0.3112.101. Seems to affect only HTTP 1.x servers.
STILL BROKEN in 62.0.3202.94  It's 5+ years later, but this bug STILL lingers! :o  Pages work just fine in FF and even in IE 11, but not in Chrome!!  Bugs like this one are a serious tarnish on Chrome... and indeed it confirms my long-standing preference for FF.  It's just a shame that a giant like Google lets serious issues like these slip by.  

On my page, I have 30 HTML5 videos with preload='metadata'.  The first 6 or so connections try to get the metadata and then THEY ALL STALL.  At that point, not only is no more metadata fetched, but all the videos on the page become unplayable.  As people were pointing out YEARS ago, Chrome seems to fail to release the connections it uses to fetch the metadata.

On my website, I'll have to change the preload to 'none' and do a lot of work to make the pages more presentable with posters, all to pander to Chrome users.  Thanks a lot, Chrome :(

Sign in to add a comment