Repository navigation
Load the start fragment again when its request is aborted before anything is buffered - #8115
Merged
robwalch merged 2 commits intoOct 23, 2026
Conversation
…hing is buffered Requesting a fragment moves nextLoadPosition to the end of that fragment. When the request is aborted before anything has been buffered, for example because a playlist for another level loaded while the start fragment was in flight, abortCurrentFrag() set nextLoadPosition to the playhead. Before hasEnoughToStart the playhead is that same nextLoadPosition, so the next fragment was selected from the end of the aborted one and the start position was never buffered. Move the load position back to the start position when it falls inside the aborted fragment, or to the start of the fragment otherwise. Fixes video-dev#8109 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
robwalch
requested changes
Oct 23, 2026
Before anything is buffered, lastCurrentTime holds the start position, so abortCurrentFrag() can use it instead of the playhead (which is the load position that loading the aborted fragment advanced), as onFragLoadEmergencyAborted() already does. Once started, the playhead is still used. Replace the test that set internal state with one where an idle tick picks the start fragment, it is aborted, and the playhead is checked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
|
Thanks! Yes, Replaced the second test: an idle tick picks the start fragment, it gets aborted, and the test checks |
robwalch
approved these changes
Oct 23, 2026
1 of 3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR will...
Set
nextLoadPositiontolastCurrentTimeinstead of the playhead when a fragment request is aborted before anything has been buffered.Why is this Pull Request needed?
_doFragLoad()movesnextLoadPositionto the end of the fragment it requests. When that request is aborted beforehasEnoughToStart(for example byonLevelLoaded()afterhls.loadLevelchanges while the first fragment is loading),abortCurrentFrag()setnextLoadPositiontothis.playhead, which before start is that same advanced position. The next fragment was then selected from the end of the aborted one, so the start position was never buffered.Before start,
lastCurrentTimeholds the start position (set instartLoad()/setStartPosition()), so it is used instead, the same wayonFragLoadEmergencyAborted()already does. Once started, the playhead is still used, sincelastCurrentTimeisn't updated during playback.Are there any points in the code the reviewer needs to double check?
BaseStreamController, so audio and subtitle stream controllers get it too.abortCurrentFragtest inbase-stream-controller.tsnow also setslastCurrentTime, since that is what the position comes from before start.Resolves issues:
Resolves #8109
Checklist
I used Claude Code to write this change.