Understanding Live Playlist Re-Sync Behavior

[softworkz]

What do you want to do with Hls.js?

It's about Live TV Playback with Time-Shift buffer

I have a live playlist for TV playback where the time-shift range can cover something like the past 60 minutes.
That means (with 3s target duration) that the (live!) playlist can include 1200 segments (0 to 1199) before segments start to get removed from the beginning (after 60 minutes, segment 0 gets removed, then 1, then 2, etc)

What's the problem?

But frequently (typically after having paused for a while and then resuming playback), I get messages like this:

Playback stalling at @293.089311 due to low buffer (buffer=0.07068900000001577)
[playback-rate-controller]: Stall detected, adjusting target latency
[stream-controller]: Playback: 293.089 is located too far from the end of live sliding playlist: 329.6087888888889, reset currentTime to : 320.610

First of all, I don't understand the message - what "live sliding playlist" is it referring to?
And how can 293 be "located too far from the end of live sliding playlist"?

All segments are available, starting from segment 0 at time 0.

And why does hlsjs decide to reset the time close to the "live edge" in this case?
(it regularly re-loads the playlist and should know which segments are available)

Thanks,
softworkz

[robwalch]

See synchronizeToLiveEdge and this #3736 (comment)

"If you get "Playback: ... is located too far from the end of live sliding playlist", then you need to configure liveMaxLatencyDuration or liveMaxLatencyDurationCount to adjust max latency."

"live sliding playlist" suggests that the start and end of the playlist change with updates, but this error is mostly caused by the end being too far from liveMaxLatencyDuration even if you have a live stream that only grows and does not slide (start is always 0 and always available).

And why does hlsjs decide to reset the time close to the "live edge" in this case?
(it regularly re-loads the playlist and should know which segments are available)

The hls.js configuration options and defaults for this have not changed in v1.0. You might be running into an issue I noticed in 3736 and have a fix for coming in v1.0.1 in #3740. liveMaxLatencyDurationCount defaults to Infinity so you should not be getting this error with a DVR live stream.

[robwalch]

@softworkz can you confirm that the "Playback: ... is located too far from the end ..." resyncing is fixed for your stream in https://hls-js-1b74ca68-453f-43e4-b9f4-5e9e18e6d611.netlify.app/demo/ ? Thanks!

[softworkz]

"live sliding playlist" suggests that the start and end of the playlist change with updates, but this error is mostly caused by the end being too far from liveMaxLatencyDuration even if you have a live stream that only grows and does not slide (start is always 0 and always available).

And why does hlsjs decide to reset the time close to the "live edge" in this case?
(it regularly re-loads the playlist and should know which segments are available)

The hls.js configuration options and defaults for this have not changed in v1.0. You might be running into an issue I noticed in 3736 and have a fix for coming in v1.0.1 in #3740. liveMaxLatencyDurationCount defaults to Infinity so you should not be getting this error with a DVR live stream.

(this is not yet about your PR..)

Initially, I had this:

                    manifestLoadingTimeOut: 20000,
                    debug: true,
                    testBandwidth: false,
                    emeEnabled: false,
                    lowLatencyMode: true,
                    progressive: true

Then I added these:

                    liveMaxLatencyDurationCount: 999999999,
                    liveSyncDurationCount: 2

=> The problem still occured

Finally, I got crazy and I also added(!) these:

                    enableWorker: false,
                    forceKeyFrameOnDiscontinuity: false,
                    stretchShortVideoTrack: true,
                    maxBufferHole: 1.2

Now I couldn't see it anymore, but it's too early to say something substantial..
Update: still happens..

Now, I will try your patch of course!

[softworkz]

Will try your patch of course!

Can I cherry-pick 9ff3ab8 onto v1.0.0 or should I better merge all of the master branch up to this commit?

[robwalch]

Can I cherry-pick 9ff3ab8 onto v1.0.0 or should I better merge all of the master branch up to this commit?

If you're working on your own fork, you can do either. HEAD is pretty close to v1.0.1:

https://github.com/video-dev/hls.js/pulls?q=is%3Apr+milestone%3A1.0.1
v1.0.0...master

[softworkz]

If you're working on your own fork, you can do either.

I primarily need my own PR about progressive loading, but anyway I probably can't test a localhost non-https stream with your hosted demo (https://hls-js-1b74ca68-453f-43e4-b9f4-5e9e18e6d611.netlify.app/demo/)

HEAD is pretty close to v1.0.1:

Just wanted to make sure that the PR doesn't have any dependencies on post-v1.0.0 commits..

Hold on..

[softworkz]

Good news...I can confirm that the referenced patch fixes the issue!

Thanks, great job!

[softworkz]

A tiny follow-up question in that context:

Given the same situation as described above, let's assume that a user has paused playback.
Now it can happen, that the pause-position gets out of the time-range that is covered by the segments in the live playlist.

Assuming I would want to do something in that case like displaying a message or auto-resuming playback, what would be the best way to monitor for that situation?
(in terms of which event to monitor and which values to check)

UPDATE: Created separate issue #3794