Not able to seek long-duration hls videos

[damanV5]

trafficstars

Player crashes with the following errors when playing long-duration (approximately 5hr) hls video. On seeking, I get these errors and the player goes on buffering until it finally crashes with error : VIDEOJS: ERROR: (CODE:3 MEDIA_ERR_DECODE) Playback cannot continue. No available working or supported playlists. MediaError {code: 3, message: 'Playback cannot continue. No available working or supported playlists.'}

[welcome[bot]]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can. To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[IWTBCAdeveloper]

I'm facing the same issue with videojs version 7.20.3

[jpietek]

Hi,

I've stumbled upon the same issue and found a workaround.

Playlist watcher is the piece of code to blame: https://github.com/videojs/http-streaming/blob/cf340f2e01586827360a70599b80e1d27197f9a7/src/playback-watcher.js#L235

After every 10 buffer stalls (calculated globally per whole main.m3u8) the current playlist is being blacklisted with playlistExclusionDuration: Infinity. Then, there is no logic to block blacklisting of the last remaining playlist, so when the last one is gone we get the MediaError {code: 3, message: 'Playback cannot continue. No available working or supported playlists.'}.

One solution (for our use case at Tellyo) was to remove stalled blacklisting altogether. You could also have a blacklist timeout like 10s, but it constantly spams the warning logs with "Excessive downloading", and toggles the blacklist among the renditions back and forth. The stalled timer could also be wallclock related and calculated per single rendition.

It's 100% reproducible having hls with 180, 360, 720, 1080p renditions and forcing the rendition switch with a script that scales video.js width. Note: we use live-ui: true and we do seek the live playlist actively in the past, thus the random seek.

const widths = [ 180, 540, 720, 2160 ];

setInterval(() => {
	document.getElementById('my-video').style.width = widths[i];
	`myPlayer.currentTime(min + range * Math.random());`
	i = (i == widths.length) ? 0 : i+1;
}, 3000);

[damanV5]

Thanks @jpietek .

[misteroneill]

Thanks for the report! And thanks for the workaround @jpietek!

[harinath01]

We're facing the same issue with DASH videos. Whenever we seek long-duration videos, excessive audio segment downloading occurs, and we get a warning message Excessive audio segment downloading detected. Switching to playlist 2-placeholder-uri-2 This issue is happening across all playlists.

Although I've tried different devices, I'm still unable to reproduce the issue, and I'm not sure why audio segments are being downloaded excessively.

If you have any specific suggestions or ideas on how to prevent this issue, I'd be glad to help resolve it. Just let me know, and I can submit a pull request if necessary.

[harinath01]

Here's the DASH file we're using: https://d210875061kd5q.cloudfront.net/transcoded/c5a4dd28-5694-43da-8cb0-5048935ea31c/video.mpd

[pardeep-linius]

is it resolved, coz i am still facing the same issue @damanV5 ?

[lodravenn]

updated to lastest version of videojs fixed it