Streaming HTML5 Audio stops playing mid-play with error "Failed to load resource"
Reported by mich...@mahemoff.com, Oct 29 2012
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 Steps to reproduce the problem: 1. Play http://feedproxy.google.com/~r/twist-audio/~5/D5q-NCg4-Vo/TWiST-E300.mp3 in an audio tag What is the expected behavior? It plays all the way through. If it can't play, it pauses while it's buffering. What went wrong? It stops after some minutes. (in one case, I captured it happening at 26:35, in case that's useful, but it seems to be random). This is very erratic behaviour and doesn't always happen, but seems to happen more often recently. Example URL: http://player.fm/series/this-week-in-startups-audio/news-panel-with-marshall-kirkpatrick-and-peter-rojas-twist-300 Does it occur on multiple sites: N/A Is it a problem playing media? No Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 22.0.1229.94 Channel: stable OS Version: OS X 10.7.3 This was a reported issue a while ago (http://code.google.com/p/chromium/issues/detail?id=109751). it seems to have improved, but recently I've seen it come back again. A user also reported this happening on Windows Chrome. I noticed after the crash, that paused is false (even though it's not playing) and currentTime is accurate, ie reflects the time of the track when it crashed. Running play() cause playback to start from 0:00. Note this is using jPlayer, though it's a fairly thin layer on the HTML5 audio tag, so I doubt it's related.
Oct 30 2012,
Oct 31 2012,
Here's the redirected feedproxy link: http://cdn2.thisweekin.com/startups/itunes/TWiST-E300.mp3 I suspect this is a network issue with your CDN though (the one plugged in the beginning of the pod cast? :). I was able to repro locally using your link, but after moving it over to Google Storage or playing off a local server, it works fine: https://commondatastorage.googleapis.com/dalecurtis-shared/TWiST-E300.mp3 You will probably see issues in other browsers if this is the case, hiccups at best, playback stoppers at work.
Oct 31 2012,
It might be that there's a problem with the network, but all the content is actually present, it just erratically errors out at random positions. So surely the audio tag could be more resilient, for example pause and retry to load it, instead of user having to manually restart it. (It's not my own CDN btw.)
Nov 12 2012,
I'm seeing the same thing with recent Chrome builds: 22.0.1229.94. Playback stops with a vague "Failed to load resource" error. On the server there is no indication of any problem serving the content. The browser looks like it simply stops requesting more data. I suspect it is related to a problem with client-side handling of "resume" or similar. I never see problems with iOS 5/6 Safari against the exact same infrastructure. I'm using this (essentially) to serve content for the audio tag: http://balusc.blogspot.com/2009/02/fileservlet-supporting-resume-and.html
Dec 18 2012,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=173647 ------------------------------------------------------------------------ r173647 | firstname.lastname@example.org | 2012-12-18T04:37:18.022858Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/safe_browsing/protocol_manager_unittest.cc?r1=173647&r2=173646&pathrev=173647 Remove SafeBrowsingProtocolManagerTest.EmptyDatabase test. This code path will be re-activated in https://codereview.chromium.org/11419041, but landing this separately simplifies the diff on that CL. BUG= 158245 Review URL: https://chromiumcodereview.appspot.com/11575027 ------------------------------------------------------------------------
Dec 31 2012,
Still seeing this fwiw. e.g. just saw this stop towards the end: http://www.podtrac.com/pts/redirect.mp3/media.blubrry.com/99percentinvisible/cdn.99percentinvisible.org/wp-content/uploads/04-99-Percent-Details.mp3
Jan 5 2013,
I am able to reproduce it on Mac OSX 10.8.2 - audio is stopped and controls are grayed out.
Feb 14 2013,
running into this issue in Chrome 24.0.1312.57 on OS X 10.8 . I narrowed it down to the "Range" header. With its first request, Chrome requests the range "0-", not specifying an end, suggesting that it should be ok to send the entire file. But this fails. I didn't check every size, but sending only 1MByte back worked for me. The next request will again only specify the lower limit, and again, sending no more then 1MByte back works.
Feb 14 2013,
could u please assign this to the right owner, is there one?
Mar 10 2013,
Apr 10 2013,
I'm seeing this same issue at the following links: http://soundrown.com/Audio/Final%20Normalized/mp3/CoffeeShop%20Final%20Thirty.mp3 http://soundrown.com/Audio/Final%20Normalized/ogg/CoffeeShop%20Final%20Thirty.ogg
Jun 22 2013,
Same Issue with Chrome 27.0.1453.116 on OS X 10.8. Sending 1MB chunks seems to fix this error when chrome asks the range of "0-" for partial content .
Jul 6 2013,
Is there any update on this? I keep seeing it happen and it makes it hard to deliver long-form audio via HTML5.
Feb 5 2014,
Feb 6 2014,
folks who reported issues: are you still seeing this bug?
Feb 6 2014,
Feb 6 2014,
Yes, still seeing it on OSX stable Chrome.
Feb 7 2014,
I, too, still see this issue in Chrome on Windows 8 as well. Chrome is up-to-date at time of posting (Version 32.0.1700.107 m). There isn't a consistent time mark in the audio to cut out. Just...random. In HTML5 media events, the error throws the "onemptied()" event.
Mar 10 2014,
I'm seeing this issue on a new site with audio tag. Oddly, my staging server never had the problem, so I was blaming the production server until I realized that Safari and Firefox don't have the weird random pause issue. The problem is occurring for me on a shared hosting environment on GoDaddy. Perhaps Chrome is having some conflict with a certain server process somehow? I've requested a phpinfo() for both servers and I can post them if it might be useful. Per #18, I'll have to learn how to monitor the "HTML5 media events" to check for events. This is my audio: http://www.everythingthatmattersradio.com/new/player-page/
Mar 21 2014,
I'm also seeing this issue with my personal web site. I'm hosting on IIS and partial content is working correctly, but the browser will unexpectedly and intermittently throw up a load error while playing mp3 files, and the audio will stop. I'm not holding my breath for a fix on this since it's been ongoing so long. (This first post dates back to Oct 28, 2012). Any new leads? Thanks for all the great comments!
Jun 17 2014,
This is still happening btw. I just got it with the following episode: http://www.podtrac.com/pts/redirect.mp3/twit.cachefly.net/audio/tri/tri0155/tri0155.mp3 via https://player.fm/series/triangulation-mp3-60/triangulation-155-console-wars at 5:00 error: "Failed to load resource: net::ERR_CONNECTION_RESET" OSX 10.9.2 Version 35.0.1916.153
Aug 3 2014,
I'm also experiencing this issue, hosting on IIS. I've made sure no timeouts are occurring anywhere server-side, and even set MinBytesPerSecond to zero to ensure IIS wasn't terminating the connection. Still experiencing disconnects in the middle of playback. Fairly consistent per-file, but otherwise seemingly random!
Aug 4 2014,
rvargas: Would you have a chance to look at this? If too busy, let me know.
Aug 4 2014,
This issue seems to be between Chrome and certain versions of website hosting software. After updating my Apache web server the issue ceased. Using Chrome version "36.0.1985.125 m" as the control group, I tested HTML5 audio across several websites, each using multiple audio codecs. Results were the problem occurred on specific websites, regardless of audio codec used. I tested the same group of websites in Firefox and Internet Explorer. Neither Firefox/IE experienced the issue on any of the websites (excluding results where the browser did not support a particular codec). Therefore, I believe the issue may reside with certain versions of web hosting software. Not 100% accurate, but progress none the less. Further testing is encouraged.
Aug 4 2014,
@amillion Would you know which versions of Apache you were using before/after. It might help devs to replicate this.
Aug 4 2014,
New version- Server version: Apache/2.4.9 (Win64) Apache Lounge VC11 Server built: Mar 16 2014 12:42:59 Old version was Apache/2.2.24 (Win32) Apache Lounge VC10 Don't have any more info on the old version.
Aug 4 2014,
Does anybody has a link to something that fails consistently? How about generating a net-internals log and attaching that here? http://www.chromium.org/for-testers/providing-network-details net::ERR_CONNECTION_RESET suggests a connectivity issue, not something specific to a range request effectively for the whole resource. It seems more likely to find such errors with resources of more than 50MB, as the files reported here.
Aug 4 2014,
I've never found anything that consistently fails unfortunately. There seems to be an example and some more info in this related or duplicate bug: https://code.google.com/p/chromium/issues/detail?id=337468
Aug 5 2014,
Here is a pause I was able to reproduce, Not from screenshot that the file has buffered past the halt in playback. Most bandcamp links I have this issue with will pause at the same point in the song every time it happens, but it may not happen every time. If I refresh the page it downloads a fresh copy of the song instead of the cached version, which happens when playback works fine. this is purely speculative but maybe a premature cache purge? URL: http://woob.bandcamp.com/album/repurpose
Aug 5 2014,
This is not related to caching. The effect from the screenshot just says that the player pauses playback when it receives an error, even if there is buffered data to play. Also, note that when reading back from the cache (which should happen even if the first download was interrupted), the UI will show the same thing: a buffering line that grows slowly, as things are read from the cache... the 'download' speed is not limited by the network/cache. The error from the log: t=486116 [st=484538] SOCKET_BYTES_RECEIVED --> byte_count = 16384 t=486116 [st=484538] SOCKET_BYTES_RECEIVED --> byte_count = 32768 t=488176 [st=486598] SOCKET_READ_ERROR --> net_error = -101 (ERR_CONNECTION_RESET) --> os_error = 10054 t=488176 [st=486598] -SOCKET_IN_USE WSAECONNRESET(10054): Connection reset by peer. An existing connection was forcibly closed by the remote host. So basically the OS is telling us that we are not going to get anything else from that socket. The headers indicate that we are about 2MB short of receiving the whole resource. I'm still trying to repro with that link, but so far no luck.
Aug 6 2014,
I could not repro this. Something else that could be at play here is that we may stretch the request for a long time (more than an hour) even if we could download the whole resource way faster, because it is throttled by the player itself. Maybe the server, or someone between the client and the server becomes impatient with that long lived request and resets it. Some things we could do to improve the experience: 1. Play back all the data that we have buffered, don't stop as soon as we receive an error. 2. If we get an error, issue another request for the rest of the content, without pausing playback. 3. Increase the max buffer size for audio (although doing so may increase the delay between subsequent reads, which may be worse from the point of view of someone considering the connection to be taking too long). So far I don't see anything wrong from the point of view of the network code, so I'm sending this back to the media team.
Aug 7 2014,
>as things are read from the cache... the 'download' speed is not limited by the network/cache. This is how I determine its loading from cache, bandcamp throttle their content, you'll see it loads about 30s instantly, but the rest slowly crawls (along the lines of the 1-2x the audio bitrate) if it loads from the cache, the entire thing is almost instantaneously loaded up to point where it previously stopped. I might pop an email to bandcamp and complain again, point them towards this thread and show them that its their server messing up the connection.
Aug 7 2014,
> if it loads from the cache, the entire thing is almost instantaneously loaded up to point For that page specifically, this may or may not be the case, depending on what the player is trying to do. If it is trying to play from the current position, then yes... but if it is trying to play the song again from the beginning, content will load slowly even if it comes from the cache. The *real* way to see where it is coming from is to look at the net-internals log.
Aug 7 2014,
You could let them know if they have a dodgy server, but the fundamental issue remains that Chrome should ideally provide users with a smoother experience in the event of such situations, as do Firefox and Safari. Also, going back to the server provider is not an option for apps streaming third-party content.
Aug 7 2014,
Correct!. Errors are bound to happen anyway, and some servers may have issues but errors may come from intermediaries that the server cannot control. We should improve the final user experience.
Aug 22 2014,
Oct 2 2014,
I just noticed another long-running issue after doing a search; should these be merged? https://code.google.com/p/chromium/issues/detail?id=111281
Mar 8 2015,
This is still a regular issue for me. Serving in 1MB chunks seems to be the only workaround, and is a huge pain when you're dealing with transcoding audio on the fly, for example.
Mar 27 2015,
I've heard several complaints from users on Windows about this. Latest, it was mentioned that pausing for several hours would cause the error and restart from the start of the track.
Apr 21 2015,
May 5 2015,
I keep stumbling into this issue too, as a Chrome user, not as a developer. E.g. under http://www.chopra.com/ccl/guided-meditations, dreammedfinal.mp3, stops after 2-5 minutes. Pausing and playing doesn't help, only reloading the page. Console shows ERR_CONNECTION_RESET. Listened to the same one on IE11 with no problem.
Sep 24 2015,
Jul 2 2016,
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sep 15 2016,
I've run into this problem (or a similar one) many times with v52 and v53. For oggs and mp3s containing a voice (but not files containing only single tones) and over 3 sec, there is sometimes a 240 msec or 1 sec pause. These files were converted to ogg using sox-14-4-2 and ffmpeg-20160815-3282e31-win64-static, and the mp3's were created using dBpoweramp 16.1. The originals are WAV and don't show this problem. All of this was done on Windows 10. All of the audio elements have the preload attribute set to auto. Initially I thought this was a buffering problem because it would appear only if ~3 oggs were played in sequence before the file suffering the pause -- playing the same file a second or more away from playing any other wouldn't produce the pause. Yet the pause seems to occur always in the same seek location (different files have different seek locations for the pause). FWIW, audio controls are hidden and these are played via the play() method.
Sep 15 2017,
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Oct 2 2017,
this bug has been stale for > 1 year. close it as won't fix with StaleClosed label.
Sign in to add a comment