Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Seek nearest SYNC does not adjust stale playlists
`getPlaylistSnapshot()` can return a cached but potentially quite stale playlist that may be unsuitable for resolving a seek position. This change fixes a race conditon that can cause a failed attempt to resolve a seek position with a stale playlist. Pre-conditions for the race: * A is the cached snapshot from previous playback of playlist A * B is the selected playlist at time of the seek * \* — is current playback position in period * QQQ — positions in A cannot be seek targets from B, they have rolled out from `Timeline.Window` * WWW — are positions in A that cannot be resolved in A, but would be in A` ``` +=================*==+ | Period | +=================*==+ +QQQ-------+ | A | +QQQ-------+ +-------WWW+ | B | +-------WWW+ seek and switch back to A occur here... +----------+ | A' | +----------+ ``` The seek request is issued with `Timeline.Window` from playlist B, yet the call to `getAdjustedSeekPositionUs()` occurs: 1. After the current track selection swithces back to A 2. But before playlist snapshot A` is loaded, replacing the old A The check is simple, does basic sanity check on `targetPositionInPlaylistUs` (that it is < durationUs of the selected playlist). This covers the positions WWW.
- Loading branch information