Seek back to unbuffered start of VOD re-downloads first fragment in infinite loop (video track never appended) on 1.6.16 — appears fixed in 1.7.0-beta.2

[damonshen17]

What version of Hls.js are you using?

1.6.16 (reproduces). Not reproducible on 1.7.0-beta.2 — details below.

What browser (including version) are you using?

Chrome 149 (macOS 15 / Darwin 25.5.0)

What OS (including version) are you using?

macOS 15

Test stream

https://video.deeplearning.ai/JupyterAI/C1/L0/sc-JupyterAI-C1-L0-master.m3u8 (VOD, TS segments, 3 variants, CORS enabled, EXT-X-MEDIA-SEQUENCE:1, 10.000s segments). Segments are healthy: continuous PTS across the playlist (seg1 video starts 0.067s, seg2 10.077s, seg3 20.087s per ffprobe), identical characteristics across levels.

Configuration

{ startPosition: 28.8 }

plus a pinned quality level at startup (hls.currentLevel = 1 inside MANIFEST_PARSED). Setting hls.startLevel instead does not change the outcome as long as the first fragment is not buffered before seeking back.

Steps to reproduce

1. Start playback mid-stream with a pinned level, so the beginning of the VOD is never buffered. E.g. new Hls({ startPosition: 28.8 }) and set hls.currentLevel = 1 at MANIFEST_PARSED. Buffered ranges become [20, …] — sn=1/sn=2 are (expectedly) not loaded.
2. After a few seconds of playback, seek back: video.currentTime = 0.

Minimal self-contained repro page:

<video id="video" controls muted width="640"></video>
<script src="https://cdn.jsdelivr.net/npm/hls.js@1.6.16/dist/hls.js"></script>
<script>
const video = document.getElementById('video');
const hls = new Hls({ startPosition: 28.8 });
hls.on(Hls.Events.FRAG_LOADING, (_e, d) => d.frag.type === 'main' &&
  console.log('FRAG_LOADING sn=' + d.frag.sn + ' level=' + d.frag.level));
hls.on(Hls.Events.BUFFER_APPENDED, (_e, d) => {
  const f = tr => { const o = []; for (let i = 0; i < (tr?.length || 0); i++)
    o.push('[' + tr.start(i).toFixed(2) + ',' + tr.end(i).toFixed(2) + ']'); return o.join(' ') || 'empty'; };
  console.log('BUFFER_APPENDED sn=' + d.frag?.sn, 'video=' + f(d.timeRanges?.video), 'audio=' + f(d.timeRanges?.audio));
});
hls.on(Hls.Events.MANIFEST_PARSED, () => { hls.currentLevel = 1; });
hls.loadSource('https://video.deeplearning.ai/JupyterAI/C1/L0/sc-JupyterAI-C1-L0-master.m3u8');
hls.attachMedia(video);
video.play();
setTimeout(() => { video.currentTime = 0; }, 6000);
</script>

Expected behaviour

The seek to 0 loads sn=1 once, appends both tracks, and playback resumes from 0 within roughly one fragment-load time.

What actually happened?

hls.js enters an infinite re-download loop of sn=1 (one request per ~100ms tick, indefinitely — hundreds of downloads of the same segment). Each cycle, FRAG_BUFFERED fires and the audio SourceBuffer gains [0.00, 9.99], but the video SourceBuffer never gains the range — so video.buffered (track intersection) never covers position 0, the stream controller sees the hole persist, re-requests sn=1, and the element stays at readyState=1 (HAVE_METADATA) forever. No fatal error is raised.

Event log excerpt (timestamps relative to page load; seek to 0 at +6000ms):

+6180ms FRAG_LOADING sn=1 level=1
+6199ms BUFFER_APPENDED sn=1 video=[20.00,80.06] audio=[0.00,9.99] [20.00,80.07]
+6201ms FRAG_BUFFERED  sn=1 level=1 [0.00-9.99]
+6207ms FRAG_LOADING sn=1 level=1          <-- 100ms later, same fragment again
+6228ms BUFFER_APPENDED sn=1 video=[20.00,80.06] audio=[0.00,9.99] [20.00,80.07]
... repeats every ~100ms indefinitely (observed >150 downloads over 15s)

The loop only breaks if an ABR level switch happens: with auto level, once the loader switched levels, sn=1 of the other level appended fine (both tracks) and playback recovered. With a manually pinned level there is no switch, so it never recovers.

Version matrix (same page, same stream, same steps)

Version	Result
1.6.16 (latest stable)	Infinite sn=1 reload loop, video track never appended, stuck at readyState=1
1.7.0-beta.2	Recovers in ~100ms: single sn=1 fetch, video [0.05,10.06] + audio [0.01,10.06] appended, then sn=2 backfills

Notes / possibly related

• Seeking backwards behind buffered range leads to significant buffering #7576 / fixed issue with seeking backward leading to stalling OR elevated buffering #7577 ("Seeking backwards behind buffered range leads to significant buffering", milestone 1.7.0) looks like the closest fix — but the symptom here is stronger than elevated buffering: a permanent, bandwidth-wasting re-download loop where the video track of the fragment is silently dropped on append while audio succeeds.
• Infinite loop loading first fragment with a hole #5609 has a similar first-fragment loop signature but was triggered by corrupted media; the segments here are healthy (continuous PTS, plays fine from 0 when sn=1 is buffered at startup).

Ask

1. Can you confirm which change in 1.7.0 fixed this (is it fixed issue with seeking backward leading to stalling OR elevated buffering #7577, or something else), so we can track the release that carries it?
2. Is a backport to 1.6.x feasible? 1.6.16 is the latest stable and the loop is easy to hit for any player that pins a quality level and restores a saved playback position (we hit it in production behind Vidstack).

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues (closest: Seeking backwards behind buffered range leads to significant buffering #7576, Infinite loop loading first fragment with a hole #5609 — differences explained above)
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

[damonshen17]

Follow-up with an isolation experiment that pins down the trigger — the loop only occurs when the playlist's EXTINF durations are inaccurate, causing cumulative playlist-vs-PTS drift.

Our variant playlists declare #EXTINF:10, but the segments' real duration is 10.0433s (ffprobe), so playlist-derived fragment start times drift ~43ms per segment behind actual PTS. I served locally modified copies of the same playlists (segment URIs still pointing at the CDN) and re-ran the identical scenario (pinned level via currentLevel at MANIFEST_PARSED, startPosition: 28.8, seek to 0 after 6s, hls.js 1.6.16):

Playlist variant	EXT-X-MEDIA-SEQUENCE	EXTINF	Seek-to-0 result
original (control, locally served)	1	10 (real: 10.0433s)	❌ infinite sn=1 reload loop, video track never appended
media-sequence fixed only	0	10	❌ same infinite loop
accurate EXTINF only	1	10.043333	✅ single fetch, video [0.07,10.08] + audio append, playable in 101ms
different stream, old pipeline (accurate EXTINF 11.2112/9.6096, MS=0)	0	accurate	✅ single fetch, recovers

So EXT-X-MEDIA-SEQUENCE is irrelevant; the drift is the trigger. Reading of the mechanism: initPTS gets anchored by the first-demuxed fragment (sn=3 here: playlist start 20.00 vs real PTS 20.087 → ~87ms offset), so when sn=1 is later fetched into the hole, its remuxed video samples map to a slightly negative start (~−0.02s) and the append produces no buffered range for the video track (audio survives, presumably because it can be trimmed per-frame at 0). The stream controller sees the hole persist and re-requests sn=1 every tick — indefinitely.

With accurate EXTINF the drift is 0 and the same content plays fine, and on 1.7.0-beta.2 even the drifting playlist recovers — so 1.7.0 handles it, but 1.6.16 turns a ~40ms/segment EXTINF inaccuracy into a permanent stall + unbounded re-download loop. Hope this helps narrow down which 1.7.0 change covers it and whether it's backportable.

[robwalch]

It looks like video is missing on seek back to 0, so my best guess is that the fix is in #7537. Since this change is part v1.7, and it was part of several changes to improve timestamp recalculation, I'm not sure if it would work as a standalone fix. It might be better overall to look at the changes on mp4-remuxer.ts‎ between latest and dev: v1.6.16...c43ad3d#diff-fccedeec0ef12b083f3e18534af86e02cecca386bce4d9f328048b5423f2e9e3R383 as a viable patch would likely need to take most if not all of the remuxer changes, considering external decencies.

The history shows several changes that together would be needed to make a reliable fix:

https://github.com/video-dev/hls.js/commits/bfb69077b57cfe73b4f64e2b4609027c2b47a49b/src/remux/mp4-remuxer.ts

• Timestamp offset stability fix for muxed audiovideo mp4 #7436 (some parts required for subsequent changes)
• Fix seeking back in live with timestamp wrapping (1.6.6 regression) #7537 / d819b45
• Adjust initPTS when switching results in dropped GoP at start #7700
• fix: correct computeInitPts rollover condition causing segment 0 loop  #7752

After #7752 work switched to I-Frame support.

[Exeton]

I'm getting a similar version of this issue, but it's not fixed when using 1.7.0-beta (https://cdn.jsdelivr.net/npm/hls.js@1.7.0-beta.2/dist/hls.min.js).

I have a playlist that gets more clips added. Here's an example playlist

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:1
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:EVENT
#EXTINF:1.000,
segment?segmentUri=segment_0.ts

#EXTINF:1.000,
segment?segmentUri=segment_1.ts

#EXTINF:1.000,
segment?segmentUri=segment_2.ts

#EXTINF:1.000,
segment?segmentUri=segment_3.ts

Using a config of

config = {

}

The player will start near the end of the live stream, and won't be able to seek to before the starting point.

Whatever I set the startPosition to is how far I can seek back to.

config = {
    startPosition: 0
}