Skip to content

Load the start fragment again when its request is aborted before anything is buffered - #8115

Merged
robwalch merged 2 commits into
video-dev:masterfrom
b84330808:bugfix/abort-start-frag-before-buffered
Oct 23, 2026
Merged

robwalch merged 2 commits into
video-dev:masterfrom
b84330808:bugfix/abort-start-frag-before-buffered

Conversation

@b84330808

@b84330808 b84330808 commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

This PR will...

Set nextLoadPosition to lastCurrentTime instead of the playhead when a fragment request is aborted before anything has been buffered.

Why is this Pull Request needed?

_doFragLoad() moves nextLoadPosition to the end of the fragment it requests. When that request is aborted before hasEnoughToStart (for example by onLevelLoaded() after hls.loadLevel changes while the first fragment is loading), abortCurrentFrag() set nextLoadPosition to this.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, lastCurrentTime holds the start position (set in startLoad() / setStartPosition()), so it is used instead, the same way onFragLoadEmergencyAborted() already does. Once started, the playhead is still used, since lastCurrentTime isn't updated during playback.

Are there any points in the code the reviewer needs to double check?

  • The change is in BaseStreamController, so audio and subtitle stream controllers get it too.
  • The existing abortCurrentFrag test in base-stream-controller.ts now also sets lastCurrentTime, since that is what the position comes from before start.

Resolves issues:

Resolves #8109

Checklist

  • changes have been done against master branch, and PR does not conflict
  • new unit / functional tests have been added (whenever applicable)
  • API or design changes are documented in API.md

I used Claude Code to write this change.

…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>
Comment thread tests/unit/controller/stream-controller.ts Outdated
Comment thread src/controller/base-stream-controller.ts Outdated
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>
@b84330808

Copy link
Copy Markdown
Contributor Author

Thanks! Yes, lastCurrentTime does it. Before start it's the start position, so abortCurrentFrag() now uses it instead of the playhead, like onFragLoadEmergencyAborted() does. After start it still uses the playhead, since lastCurrentTime doesn't follow playback. I went with this rather than changing the playhead getter, which has a lot of other callers.

Replaced the second test: an idle tick picks the start fragment, it gets aborted, and the test checks playhead. Also had to set lastCurrentTime in the existing abortCurrentFrag test in base-stream-controller.ts.

@robwalch robwalch added this to the 1.7.4 milestone Oct 23, 2026
@robwalch
robwalch merged commit 98afb3f into video-dev:master Oct 23, 2026
12 checks passed
@github-project-automation github-project-automation Bot moved this from Top priorities to Done in HLS.js Release Planning and Backlog Oct 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Seek-target fragment skipped after quality switch, causing playback stall

2 participants