Loop after seeking to the end of some contents

[testeur-990]

We are experiencing a playback loop when seeking to the end of some streams on certain platforms, such as Tizen 5.5. After seeking to the end, the player repeatedly requests the last video segment, appends init fragments, and adjusts the playback time due to a small gap detected in the manifest.

See below for an excerpt of the logs.

[1762527474955 61124] I [PlaybackController] Requesting seek to time: 4561.82
[1762527474955 61137] I [PlaybackController] Seeking to: 4561.82
[1762527474955 61142] D [Stream] onBufferingCompleted - One streamProcessor has finished but video one is not buffering completed
[1762527474955 61147] D [FragmentModel][text] abort requests
[1762527474955 61154] D [SourceBufferSink][text] Updated append window for text. Set start to 0 and end to 4561.93
[1762527474955 61205] D [BufferController][video] Got enough buffer to start
[1762527474955 61218] I [PlaybackController] Native video element event: seeked
[1762527474955 63073] I [StreamProcessor][video] Buffer is empty! Stalling!
[1762527474955 63074] D [BufferController][video] Waiting for more buffer before starting playback
[1762527474955 65051] W [GapController] Jumping to end of stream because of gap from 4561.894 to 4561.92. Gap duration: 0.02599999999983993
[1762527474955 65053] I [PlaybackController] Requesting seek to time: 4561.92
[1762527474955 65062] I [PlaybackController] Seeking to: 4561.92
[1762527474955 65065] D [FragmentModel][video] abort requests
[1762527474955 65067] D [Stream] onBufferingCompleted - One streamProcessor has finished but video one is not buffering completed
[1762527474955 65070] D [FragmentModel][text] abort requests
[1762527474955 65075] D [SourceBufferSink][video] Updated append window for video. Set start to 0 and end to 4561.93
[1762527474955 65079] D [SourceBufferSink][text] Updated append window for text. Set start to 0 and end to 4561.93
[1762527474955 65091] D [ScheduleController][video] Quality has changed, get init request for representationid = video=5325200
[1762527474955 65095] D [BufferController][video] Appending init fragment for type video, representationId video=5325200 and bandwidth 5325200
[1762527474955 65104] D [StreamProcessor][video] Appended bytes for video and stream id 1
[1762527474955 65108] I [StreamProcessor][video] [video] lastInitializedRepresentationId changed to video=5325200
[1762527474955 65113] D [ProtectionController] DRM: onNeedKey
[1762527474955 65115] D [ProtectionController] DRM: Ignoring initData because we have already seen it!
[ScheduleController][video] Media segment needed for video and stream id 1
[StreamProcessor][video] Adjusting playback time 4561.82 because of gap in the manifest. Seeking by -0.1000000000003638

Questions:

• Could you please explain why Dash.js loops on the last segment when a small gap is detected in the manifest?
• Is there a recommended way to handle seeking to the end of these streams so that playback stops cleanly without looping?

Note
I just tested this stream: http://refapp.hbbtv.org/videos/tears_of_steel_1080p_25f75g6sv3/manifest.mpd
and after seeking to the end, I also get the same warning:
[1762535289962 1320178] W [StreamProcessor][11][video] Adjusting playback time 734.06 because of gap in the manifest. Seeking by -0.10000000000002274, just like with our streams.

Thanks in advance

[dsilhavy]

The seek is triggered because the signaled content duration in the manifest 734,16 is longer than the summed up duration of segments signaled in the audio manifest:

(263177 + 264192 * 121 + 144384) / 44100 = 734,1222902494

When seeking to a time larger than 734,1222902494 the player does not know which audio segment to fetch since there is no audio segment signaled for that specific time. In that case, we seek back to the last possible position.

However, it should not trigger a loop. Does that only occur on SmartTVs? Or do you see the same behavior on Desktop browsers?

With the HbbTV Reference stream you provided, I also see the seek but then the playback terminates correctly.

[testeur-990]

Hello @dsilhavy
Does that only occur on Smart TVs? Or do you see the same behavior on desktop browsers?
⇒ I did more tests on Tizen 5.5 and I can reproduce it systematically.

With the HbbTV reference stream you provided, I also see the seek, but then playback terminates correctly.
⇒ I also did more tests with this stream — Yes, I observed the same behavior: there’s no loop. I get the warning but no looping issue — but that’s not the case with our streams.

Please see below the MPD and additional logs from our streams.

logs-to-share.txt

mpd-to-share.xml

[testeur-990]

Hello @dsilhavy ,
I’ve analyzed the logs and I believe I understand why a playback loop occurs when seeking to the end of our streams npvr
Here’s what happens in detail:

When seeking to the end of the stream (Requesting seek to time: 4561.92), your StreamProcessor’s gap workaround (https://github.com/Dash-Industry-Forum/dash.js/pull/4658/files) is triggered because the buffering time is at or beyond the last segment

This causes Dash.js to seek slightly backward (4561.92 → 4561.82) to avoid requesting a segment outside the manifest.

After this adjusted seek, the GapController detects a small residual gap at the end of the stream:
Jumping to end of stream because of gap from 4561.894 to 4561.92

This triggers another seek to the end, which then re-triggers the StreamProcessor workaround.

As a result, the two mechanisms interfere with each other, creating a loop:
Seek → StreamProcessor adjust (-0.1) → GapController detects gap → Seek → StreamProcessor adjust → ...

Could you please advise if there is a recommended way to handle this scenario?

[testeur-990]

Hello @dsilhavy ,
Please, do you have any suggestion regarding this issue?

[dsilhavy]

@testeur-990 Any way you can share the stream privately with me? I assume it can be reproduced in Desktop browsers as well?

[testeur-990]

Hello @dsilhavy ,
Unfortunately, I’m not able to share the stream privately because it is fully integrated inside a client application, and I don’t have direct access to the raw URL.

Also, the issue cannot be reproduced on desktop browsers.
On desktop, Dash.js does not detect a gap at the end of the stream, so the StreamProcessor’s small seek workaround (currentTime - 0.1) works correctly and we get the ended event.

However, on Tizen, Dash.js does detect a small gap at the end of the stream, and then the jump-to-end logic in GapController is triggered:
const timeToStreamEnd = playbackController.getTimeToStreamEnd();
if (isNaN(seekToPosition) && playbackStalled &&
isFinite(timeToStreamEnd) && !isNaN(timeToStreamEnd) &&
timeToStreamEnd < smallGapLimit) {
const endTime = parseFloat(playbackController.getStreamEndTime().toFixed(5));
seekToPosition = endTime;
jumpToStreamEnd = true;
}

Because of this, the GapController “jump-to-end” seek interferes with the mini-seek done by StreamProcessor, and the player enters a loop (continuous seeks between the two positions). On TV we never reach a stable state and therefore never receive the ended event.

What I would like to know is whether, in this specific jump-to-end scenario, it would make sense to handle very small gaps differently — for example, if the detected gap is extremely small (e.g. < 0.1s) and playback is already stalled near the end, would it be acceptable to trigger the ended event directly instead of looping?

I’m mainly looking for suggestions or guidance from your side on how we can better handle this edge case.
Thanks!

[dsilhavy]

@testeur-990 Do you have the chance to debug this a bit more. I would like to know that is in lastGapJumpPosition in the GapController. It is hard to manually follow the issue you are describing without being able to debug this. However, I we usually check lastGapJumpPosition !== seekToPosition !== seekToPosition before doing the gap jump. So I wonder what is in lastGapJumpPosition as seekToPosition always seems to be the same in your case.

I assume lastGapJumpPosition is reset to NaN before the next gap jump is triggered?

[testeur-990]

Hello @dsilhavy ,

I just implemented a workaround that forces emitting the ended event in this case in the StreamProcessor if it hasn't been emitted, and it seems to work. Thank you for your support.