SEEK_NEAREST does not adjust based on stale playlists #10477
Conversation
`getAdjustedSeekPosition()` fails to return a valid value if a track selection updates the selected track followed by a seek operation, but before the updated track has issued the first playlist refersh. This occurs because the playlist for the new selected track has not yet been: 1. established as the primary playlist (`getNextChunk()` will do this) 2. Performed an initial load 3. Reported the `onPrimaryPlaylistRefreshed()` up to the main playback thread The old code used `getPlaylistSnapshot()` can return a cached but potentially quite stale playlist that is unsuitable for resolving a seek position. The fix is to introduce a method, `HlsPlaylistTracker.getFreshPrimaryPlaylist()` that only returns a playlist snapshot that is currently primary and recently loaded.
| boolean isFresh = playlistBundle.isSnapshotFresh(); | ||
| return isPrimary && isFresh ? playlistBundle.getPlaylistSnapshot() : null; | ||
| } | ||
|
|
There was a problem hiding this comment.
Only the current primary HlsMediaPlaylist is up to date with the Period/Timeline used by ExoPlayerImplInternal, and only if it has been loaded (and thus reported the MediaSource.
| || playlistSnapshot.playlistType == HlsMediaPlaylist.PLAYLIST_TYPE_EVENT | ||
| || playlistSnapshot.playlistType == HlsMediaPlaylist.PLAYLIST_TYPE_VOD | ||
| || updateDelta <= C.usToMs(playlistSnapshot.targetDurationUs * 2); | ||
| } |
There was a problem hiding this comment.
Possible the TYPE_EVENT should also be checked for freshness rather then assuming it is.
Note once it has updated once it may be overkill to check delta < target duration (as this is already covered by the stuck playlist check for primary), so just is primary and has updated (lastSnapshotLoadMs != 0 or just playlistSnapshot != null). If so, this method may not be needed.
The comment "all should be same" is not correct, it is extremely likely they will be the same but not assured. In either case the seek position will work, it just may not land exactly on a sync point in every variant.
|
See conversation in 530dd3f for more details. It may be we can solve the problem in a slightly simpler way than this approach. |
|
Canceling this, the simpler fix is in the works. Thanks @tonihei for your help on this! |
getAdjustedSeekPosition()fails to return a valid value if a track selectionupdates the selected track followed by a seek operation, but before the
updated track has issued the first playlist refersh.
This occurs because the playlist for the new selected track has not yet been:
getNextChunk()will do this)onPrimaryPlaylistRefreshed()up to the main playback threadThe old code used
getPlaylistSnapshot()can return a cached but potentially quite stale playlistthat is unsuitable for resolving a seek position.
The fix is to introduce a method,
HlsPlaylistTracker.getFreshPrimaryPlaylist()that only returnsa playlist snapshot that is currently primary and recently loaded.