I too seem to be having this issue, the result for me being a hung Tab that I have to manually close. My stackoverflow comment below:

"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."

I can see this here too, only happens under Chrome

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

Thanks for pointing out the Chrome bug. Depending on the use case it seems like using preload="none" could help.

We also added some additional cleanup for video elements when they're disposed of, where load() is called on an empty source element like in one of the suggestions on the chrome bug thread. Not sure if that will help this case specifically.
https://github.com/videojs/video.js/blob/master/src/js/media/html5.js#L282

Just had a similar bug happen and found several Chrome issues referencing this bug or something similar. In my case, the first of my elements was an mp4 in a list of ogg, webm, and flv.

For whatever reason, Chrome would choke on the mp4 file. It was encoded with x.264:

avconv -i myvideo.mp4
avconv version 0.8.9-6:0.8.9-0ubuntu0.13.10.1, Copyright (c) 2000-2013 the Libav developers
  built on Nov  9 2013 19:09:46 with gcc 4.8.1
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'myvideo':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2012-12-11 06:11:36
    encoder         : Lavf54.6.100
  Duration: 00:01:19.83, start: 0.000000, bitrate: 459 kb/s
    Stream #0.0(und): Video: h264 (High), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 351 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc
    Metadata:
      creation_time   : 2012-12-11 06:11:36
    Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16, 97 kb/s
    Metadata:
      creation_time   : 2012-12-11 06:11:36

The weirdest thing is a different video, encoded the same way/matching the above output, works just fine.

We fixed (hacked) around this bug by doing the following:

1. added preload="none"
2. moved the <source> containing the "broken" mp4 below the webm reference.

Chrome now loads the webm video first and does not choke on the mp4.

@timelf123 that's odd behavior. There's some MP4 related issues with Chrome for linux, but this sounds file specific. You might try re-encoding the first file, or running it through Zencoder which can fix a number of oddities.

It looks like the issue is still pending in Chrome. I'm going to close this since I don't' think there's anything we can do in video.js to prevent this, but if there's any new information please post it here.

Any news on this issue?

Still not solved.. kick.

I've been following the Chrome issue for... a while now: https://code.google.com/p/chromium/issues/detail?id=234779

Follow the threads and you might find a temporary solution, but it looks like Chrome is dragging its heels on this one.

Believe it or not, this works for me. I just have to execute this before any new video is added. NOTHING ELSE worked for me.

    // this hack clears up any pending socket issues. damn it chrome.
    if(window.stop !== undefined) {
        window.stop();
    } else if(document.execCommand !== undefined) {
        document.execCommand("Stop", false);
    }

@booherbg This worked for me too! Thanks for sharing!

@booherbg Thank you! It works!

This didn't work for me unfortunately. (I'm using just the video tag and replacing the src dynamically)
I had to set preload to none.

Bumped on this today. Common Chrome, employer blames this shit on me! It's bloody 2019.

Setting preload to none doesn't seem to do the thing.

@jayarjo have you found a workaround for this? I'm facing the same issue in 2021.