43

I have a weird issue in Chrome.

Each time I load a <video> element, chrome will start two HTTP request.

The first one will stay pending forever (I guess this is the "meta-data", "partial content" request. But the point is that it stay pending)

The second one to the same file is ok and goes on and close after the loading is over.

The problem here is that the first request stay pending until I close the browser page. So at some point, if I load multiple video, Chrome will break and stop downloading anything because every available request is occupied by these pending requests.

I created a reduced test case here: http://jsbin.com/ixifiq/3

I've check to reproduce the issue, and it is happening on both Video.js and MediaElements.js frontpages. Open your network tab when loading the page, you'll see the first pending request. Then press play on the video, and you'll see the second request working, but the first one will stay pending forever.

Does anyone knows a fix to this bug?

Simon Boudrias
  • 38,416
  • 12
  • 90
  • 126
  • I tested it out on Youtube HTML5 video mode, and I think the same bug is occurring over there... – Simon Boudrias Apr 22 '13 at 23:51
  • If you directly request the video, does the browser play it correctly, or can you observe the same behaviour? – Lachlan McD. Apr 23 '13 at 02:28
  • You mean directly request via a ` – Simon Boudrias Apr 23 '13 at 03:08
  • What about a [directly linking to the video's URL](http://mediaelementjs.com/media/echo-hereweare.mp4)? – Lachlan McD. Apr 24 '13 at 05:42
  • @nness Oh, that's working correctly without pending request. – Simon Boudrias Apr 24 '13 at 13:16
  • When I use the direct video URL, not running through an HTML page with a video tag etc, my Chrome network tab tells me the request is made thrice with the following Statuses: "(canceled)", "(pending)", "200 OK", in that order. The mp4 loads however. In my video.js context in an HTML page, the request also happens thrice, but intermittently fails - resulting in a hung tab which I must close manually. – danjah May 23 '13 at 04:32
  • Similar: [Chrome hangs after certain amount of data transfered - waiting for available socket](http://stackoverflow.com/q/23679968/55075) at SO – kenorb Mar 07 '16 at 21:26

7 Answers7

21

(This bug still exists in Chrome 38.0.2125.111, OS X 10.10)

This may be a Chrome bug & you may solve it without any dummy ?time-suffix trick, just helping Chrome releasing sockets faster:

I had the same bug on a RevealJs HTML presentation, with 20+ videos (one per slide, autoplayed on slide focus). As a side effect, this unreleased socket problem also affected other ajax-lazy-loaded medias following immediately the first pending/blocked video, in the same HTML DOM.

Following Walter's answer (see bug report), I fixed the issue following the next steps:

1- Set video preload attribute to none:

<video preload="none">
    <source src="video.webM" type="video/webM">
</video>

2 - Use a canplaythrough event handler to play and/or pause the video once it is loaded & ready. This helps Chrome releasing the socket used to load that video :

function loadVideos(){
    $("video").each(function(index){
            $(this).get(0).load();
            $(this).get(0).addEventListener("canplaythrough", function(){
                this.play();
                this.pause();
            });
    });
}
Ronan
  • 4,261
  • 3
  • 17
  • 14
  • 2
    This solution worked for me, with a page with ten HTML5 videos in webm format. Not only the page would load perfectly. Also, I can play any video or all of them at the same time. – Andrew F. Aug 15 '15 at 18:22
  • Posting this as a comment instead of an additional answer, credit goes to @user3368336 I tried Ronan's solution with the tag. All of them loaded perfectly however as soon as I try to play more than 6 audio channels at the same time 7th and the later channels don't play and on the developer console their status shows up as (pending). Please note that I am not talking about ` – Roy Scheffers Nov 20 '18 at 15:43
14

Apparently that's a bug from Chrome. And there's nothing to do about it ATM.

I reported the issue a while ago on the Chromium project and it's been assigned. So hopefully it'll be fixed in near future.

Bug report: https://code.google.com/p/chromium/issues/detail?id=234779

Simon Boudrias
  • 38,416
  • 12
  • 90
  • 126
  • 4
    I'd like to add that Chrome's connection limit considers all tabs and windows - so that one pending request might block other windows as well. In short: If Chrome is unable to play your html5 video, sometimes it's enough to close other tabs pointing to the same host. – Felix Schwarz Jul 31 '13 at 14:47
  • This bug still exists in Chrome 38.0.2125.111, OS X 10.10 – Ronan Nov 05 '14 at 15:45
  • 1
    There is a solution to this problem in the last comment by Ecropolis. Maybe we should add it to this accepted answer... – Technotronic Oct 14 '15 at 11:14
  • Sounds like [#234779](https://bugs.chromium.org/p/chromium/issues/detail?id=234779) was marked as duplicate of [#31014](https://bugs.chromium.org/p/chromium/issues/detail?id=31014) which is has been fixed in Nov 17, 2014. – kenorb Mar 07 '16 at 21:23
9

I don't know if it will be functional right now, but I remember solving this issue by adding a parameter to the video URL, just like "video.mp4?t=2123". Of course, everytime you load the video, the parameter should be different. I'd use 

var parameter = new Date().getMilliseconds();

to get it, and add it.

With this, at least a few months ago, I was able to play the same video multiple times without Chrome waiting forever the response.

Hope it helps.

Unapedra
  • 1,649
  • 2
  • 20
  • 33
  • 1
    You, my friend, saved my day. We had an issue with Chrome in the situation where we load page content (including a autoplaying html5 video element) via AJAX. Chrome would keep the video playing in the background (even after removing the complete element from the DOM), causing issues when we go back to the same page (basically it didnt show anything except for the poster image; untill the video had finished playing in the background, after that the video started playing again). Thanks! – Gerben Van Dijk Jun 13 '14 at 13:33
  • Glad I could help! Thanks for your comment @GerbenVanDijk ! – Unapedra Jun 13 '14 at 15:28
  • Hardly ideal, since it'll have to load again, but definitely a timely solution - thanks @Adracat – danjah Jul 04 '14 at 00:10
  • Caching contents makes sense. Saving bandwidth too. Definitely not a good solution :-/ – Ronan Nov 05 '14 at 15:40
  • It's as bad as not being able to do what an application is suppoused to do just because of bandwidth... – Unapedra Nov 05 '14 at 15:41
8

This bug still exists. I'm using an HTML5 video player on a single page application. After loading about 7 players with pre-buffering, I hit the limit and no more videos load. I found another answer having to do with images and I was surprised to find that this answer solves this problem.

if(window.stop !== undefined) {
    window.stop();
} else if(document.execCommand !== undefined) {
    document.execCommand("Stop", false);
}

reference: Javascript: Cancel/Stop Image Requests

Community
  • 1
  • 1
Ecropolis
  • 1,885
  • 2
  • 21
  • 26
  • For me this works, and allows the browsers to cache the video and avoid repeated requests. Thanks – ivanxuu Jun 29 '15 at 11:29
  • Worked for me when trying to load multiple mp3 files. – Technotronic Oct 14 '15 at 11:08
  • This seems to work for me. But when I go to the next slide (whose images were preloading and got cancelled) how do you get the browser to retry loading the image now its in view? Right now it's showing a broken image link. – greatwitenorth Mar 23 '16 at 16:30
7

I found this issue when using html5 video inside dynamic content such as carousels, to release the blocked sockets you have to unload the video source:

var video = $('#video');
video[0].pause();
video.prop('src','');
video.find('source').remove();
video.remove();

The bug claims to be fixed but I still had to do this on Chrome 42. At least I could still set preload="auto".

sidonaldson
  • 20,187
  • 10
  • 47
  • 54
  • 1
    You should also video.load() according to http://www.w3.org/html/wg/drafts/html/master/semantics.html#best-practices-for-authors-using-media-elements – Lodewijk Aug 06 '15 at 20:00
  • thanks, this worked for me. I have a video inside a modal which creates the – looshi Aug 19 '15 at 23:51
  • 1
    @Lodewijk: it seems that W3C cannot be trusted to use URLs that do not disappear. Up to date info at https://html.spec.whatwg.org/#best-practices-for-authors-using-media-elements – Mikko Rantalainen Jan 17 '18 at 12:36
  • this should be the answer with that green check cuz its the only one that works! thank you! – moeiscool Jun 28 '18 at 16:28
1

We had the same symptoms, but the problem was that we were calling load() on the same video twice in succession: same video control, same video source (MP4). Two identical 206 requests showed up in the dev tools, and then, after switching video a few times, Chrome would cancel the first request, turn off progressive playback, and wait for that second request to complete.

Also note that if you're using an MP4 source and it isn't formatted for progressive playback (meaning the MOOV atom is at the beginning of the file), then you will have 1-2 additional requests for the file, which makes it even more confusing.

Seth
  • 5,489
  • 4
  • 40
  • 51
0

@sidonaldson 's answer is the only one that worked for me. However I did not remove the video or source. The following code worked for me, run this just before putting the correct src and playing it.

const video = document.getElementById('player')
      video.pause()
      video.setAttribute('src', '')
      video.load()

@ecropolis's answer also worked but my SPA would end up having no images so it was not an option.

galipmedia
  • 77
  • 5