A momentary loss of connection while downloading chunks causes an exception.

[dtiesling]

Description

While streaming an HLS if connectivity is lost even for a moment the player throws an exception and locks up. A couple of retries with exponential backoff would be ideal. We are seeing lots of small drops in connection during playback.

Sources

Can be triggered on any HLS video.

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Begin streaming any HLS.
2. Disable network connection.
3. Re-enable network connection.

Results

Expected

I would expect this work in the same fashion that a progressive mp4 download works. I can kill a connection with a progressive download for a few seconds and re-enable it without issue.

Error output

{code: 2, message: "A network error caused the media download to fail part-way."}

videojs-contrib-hls version

what version of videojs-contrib-hls does this occur with?
videojs-contrib-hls 5.2.1

videojs version

what version of videojs does this occur with?
video.js 5.16.0

Browsers

what browsers are affected? please include browser and version for each

• Chrome

Platforms

what platforms are affected? please include operating system and version or device and version for each

• Windows 7

[dtiesling]

For reference I swapped in this block of code and it seems to solve the problem.

@ line 763

this.mainSegmentLoader_.on('error', function () {
        _this3.mainSegmentLoader_.pause();
        if (_this3.audioPlaylistLoader_) {
          _this3.audioSegmentLoader_.pause();
        }

        setTimeout(function(){
          _this3.mainSegmentLoader_.load();
            if (_this3.audioPlaylistLoader_) {
              _this3.audioSegmentLoader_.load();
            }
        }, 5000);
      });

[cedricve]

@dtiesling also OSX/chrome is affected.

[cedricve]

cool @leanoardo-hotmart

[gesinger]

Thanks for reporting the issue @dtiesling , and thanks for the sample code (as well as the PR using some of it from @leonardo-hotmart ).

I posted a bit over in #1042 , but I wanted to copy over some of the conversation, as well as an update on addressing this issue.

While that sample code may help relieve the problem, it may also cause some other behavior. For instance, if the requests keep erring for the same playlist, we do want to try a different one (if one is available). Or if someone tries to pause the video during the 5 second delay, then that code will automatically resume after those 5 seconds (though that can be resolved with more state management).

To address at least part of this issue, we have a PR incoming that never blacklists the final rendition available: #1026

While this means for streams with multiple renditions a loss of connection may end up blacklisting all but one rendition (for a period of 5 minutes), it should solve the problem for single rendition playlists, and will help prevent connectivity loss from blacklisting all playlists when multiple are available.

Please let us know if you have any ideas for improving/enhancing this logic, or if this solution will work for you.

[mgara]

Is there any way to actually force the player to reload the video and play it back again ? I'm trying to do a
player.on("error",function(e){
setTimeout(function(){
player.load();
}, 5000)
});
but the player goes to "stalled" State.

[mjneil]

@mgara videojs-contrib-hls does include a plugin that will reload the source on player errors. It's turned off by default, but you can turn it on by adding the plugin to your player options

var options = {
  plugins: {
    reloadSourceOnError: {}
  }
};

var player = videojs('myVideo', options);

This may not solve all the issues, but may help your scenario. That in combination with the pull requests @gesinger mentioned will probably be what you are looking for.

[leonardodiniz-hotmart]

@gesinger
Having at least one playlist out of the blacklist seems fine to me.
I believe it will solve the connection problem.

You said in your comment that now all playlists but one will be blacklisted for a period of 5 minutes.
Don't you think 5 minutes is too long?
Can't we have an option for this?

In a momentary connection loss scenario, imagine we would blacklist all playlists but a 224p.
When we have the connection back we would play 224p video for 5 minutes.
Did I get it right?

In this case I think five minutes would be too much. Most videos nowadays are 10 to 12 minutes long. Therefore we would list blacklist for 50% of the video.

What do you think about this time?
Does it make sense?

Cheers

[gesinger]

@leonardo-hotmart , while right now 5 minutes has been our standard blacklist duration, I think that, as you mentioned, an option for the blacklist duration may be a good idea.

And in the case you gave, playing on the lowest rendition for potentially 5 minutes is definitely not the optimal solution Right now, if we see that a playlist errors, we want to blacklist it and move on to the next playable playlist, regardless of what the error is (because our information regarding the error is often too limited to make a decision otherwise). But maybe a good enhancement to the current solution would be: if all playable playlists are blacklisted, instead of remaining on the last one, we shorten the blacklist duration on the others/clear the blacklist and try again after a delay.

What're your thoughts?

[leonardodiniz-hotmart]

I think that's a great idea @gesinger .
Having an option for the blacklist duration and this new approach would solve the connection loss issue and all the other factors that cloud blacklist a playlist would be covered as well.

[gesinger]

Thanks @leonardo-hotmart .

The initial fix for this issue was released as part of v5.4.0, so I'm going to close this. However, I opened #1070 and https://github.com/videojs/videojs-contrib-hls/issues/1071 to address the enhancements discussed above.

Thanks again to everyone for your input and debugging info. Please let us know if you experience any problems.