Closed renatofrota closed 2 days ago
after further testing, it seems clicking -10:00 (with only 3 minutes of playback available) player just seeks to live (considering a margin to the live edge - respecting liveSyncDuration) - not to the oldest available segment (-3:00) as I've said previously.
I've noticed another problem: after seeking back, it's possible to seek forward, closer to the live edge than configured at liveSyncDuration (even setting live-edge-tolerance). This is a serious problem for P2P implementations.
e.g.:
live-edge-tolerance="60" liveSyncDuration: 60
ideally:
Thanks a lot for the testing and feedback! I've pushed up a bunch of small fixes which should improve the live playback experience. It's really hard for me to figure it out right now as I don't have live test streams (DVR/not). If you can try out the next release (should be out today or at most next few days) that'd be awesome. Happy to keep tweaking until we get it right. I'll reopen when needed :)
When using
stream-type="live:dvr"
the trackbar allows seeking back and the trackbar "window" keeps growing despite the older segments being removed from the m3u8 playlist.e.g.: after 10 minutes in a live stream, with 3 minutes of playback segments available, the left edge of the trackbar represents the timestamp "-10:00" (instead -3:00).
The position -10:00 is clicable but player automatically seeks to "-3:00", which is the closest available segment to the timestamp selected - pretty good!! (other players seeks to the live edge or just freeze).
However, it would be an even better user experience if the tracking bar was updated to represent the available playlist segments (only the window from -3:00 to live).
[off] WHAT A GREAT PLAYER!! 👏🏽👏🏽👏🏽 Thanks @mrlika for the recommendation 😀