Migrated from 0.14.9: Auto-seeking to the latest segment on playback doesn't work anymore

[junpark-liveconnect]

What do you want to do with Hls.js?

I used 0.14.9 before and now migrating to 1.4.x.

When using version 0.14.9, if playback was initiated after a few minutes of loading, it automatically jumped to the latest segment and started playing. However, in the current version, playback starts from the paused segment even after 10 minutes of loading.

The config parameters are still provided in the same way. With the version upgrade, is there a specific config parameter that needs to be manually set to enable this feature(auto-seeking)?

What have you tried so far?

I tried liveMaxLatencyDuration, but it periodically seeks based on the amount of loaded segments, regardless of user action. This is different from seeking to a specific segment only after playback that I intend.

[robwalch]

Hi @junpark-liveconnect,

liveMaxLatencyDuration dictates whether HLS.js will seek or not when paused in a live stream as the playlist advances. If set to Infinity, or a very large value, HLS.js will not seek as long as there is buffer to play through. After resuming and playing through the available buffer, if a gap is encountered, and playback is not within the live window, HLS.js should resync with the live stream.

One way to clear the back buffer as live streams updates is to set backBufferLength. If your live stream has a window of 60 seconds, set backBufferLength to 60. If resuming playback and the buffer is empty, HLS.js should resync with the live stream.

Another solution would be to listen for "play" events on the media element, and set currentTime to seek to the live edge as you see fit.

[junpark-liveconnect]

Thanks for quick reply, @robwalch !
I found _ensureFragmentAtLivePoint function is running every tick in v0.14.9 which is not running anymore in v1.4.x.
To jump to live edge StreamController used liveSyncPosition. I searched and found HLS has liveSynsPosition field.
I use the statement video.currentTime = hls.liveSyncPosition every time it plays as the last solution you mentioned and it works how I expected.

So can I say it doesn't move to live edge automatically without the code like this?

[robwalch]

I found _ensureFragmentAtLivePoint function is running every tick in v0.14.9 which is not running anymore in v1.4.x.

In v1, synchronizeToLiveEdge is evaluated with every tick the same way that _ensureFragmentAtLivePoint was. The difference is that synchronizeToLiveEdge will not seek forward while there is media in the buffer that can still be played (media.readyState is 4). This allows resumption without jumping ahead automatically which was not possible before.

The change was introduced with this PR:

• Live stream sync fixes and improvements #3603

Based on live sync cleanup made here:

• Latency controller #3112

With issues and discussion covered in these issues to name a few:

• bugfix: Don't sync to live when media is in paused #4402
• Feature/v1.0.0 Live-stream stuck when current playing frag is out of live sliding playlist #3091
• hls.js low latency setup for live streams #3077
• How can I make sure my users are always as close as possible to the live edge of my stream? #2371

To jump to live edge StreamController used liveSyncPosition. I searched and found HLS has liveSynsPosition field.
I use the statement video.currentTime = hls.liveSyncPosition every time it plays as the last solution you mentioned and it works how I expected.

This is an acceptable solution. The same that would be required if you wanted the same behavior playing HLS natively in Safari, which was the motivation for the change.

So can I say it doesn't move to live edge automatically without the code like this?

Yes. This change was made intentionally. There was no effort to maintain the old behavior as it better achieves with the HTMLMediaElement API outside of HLS.js.

[junpark-liveconnect]

Thank you for details again.

Now I understand how it went thru all.

I'll close this. :)