Player freezes on Samsung Tizen 25 after seeking (TSTV)

[testeur-990]

Description:
On Samsung Tizen 25 devices, when performing a seek during TSTV playback, the player remains frozen in the spinner. This issue is not observed on other Tizen versions.

Observations from logs:

After a seek operation 'Requesting seek to time: 24978855.156 ' , the currentTime property spontaneously jumps ~267 seconds ahead of the buffered range immediately
` [1759151681652 13164] D [BufferController][audio] Buffered range: 24978854.08 - 24978860.095999, currentTime = 24978855.156
[1759151681652 13166] D [StreamProcessor][audio] Appended bytes for audio and stream id 0
[1759151681652 13170] D [ScheduleController][audio] Media segment needed for audio and stream id 0
[1759151681652 13171] D [StreamProcessor][audio] Next fragment request url for stream id 0 and media type audio is urlDAwNjgzMzQ1NTk%3D&frh=aHR0cHM6Ly90dnBsdXMuY29tLnRy&from=31&validdev=5499%2C5891&hms_devid=5499&vqe=3&uid=lURTDOEevX41UaWJAchD9w&sw_lh=o9Nxf8HnQhPq7VAjAInzsg&proxy=true&sw_off=270407&sw_ps=1759151690407&accountinfo=ReJB+CDKbYPxVHOtlmwWN17gZHBmxpw4CsQ3vLwVOpD1NlieID7q1uu3EKQ0wRxAHmYbjbwBQAZiH4ARBGYvmdGfz7RCkjDlKIvBkRDNQcPQC8QIeqAJXbIVcchmK4h5Hy24fu9W3eE0z40pPYg4olXmLF1%2Fm73a6HVv2iMmG58%3D%3A20250929131449%3AUTC%2C%2C%2C20250929131449%2Curn%3AHuawei%3AliveTV%3AXTV4294%2C%2C-1%2C0%2C1%2C%2C%2C2%2C246%2C%2C%2C2%2C%2C0%2C%2C%2C%2C%2C2%2C1%2C158997784%2CEND&st=pacoSimeSzZTjr3tndUHlLYSCleSWqM7efUf2-Yrlsk&e=MTgwMA&ts=MTc1OTE1MTY5MA with request range null
[1759150726858 967986] L [player] [PlayerDashjs] dispatchDashEvent_: bufferStateChanged event.state bufferStalled
[1759150726858 967987] I [player] [Player] notifyDashBuffering: buffering, mediaType, this.dashVideoBuffering_, this.dashAudioBuffering_, this.dashAllBuffering_ true video false false true
[1759151681652 13195] I [StreamProcessor][video] Buffer is empty! Stalling!
[1759151681652 13197] D [BufferController][video] Waiting for more buffer before starting playback
[1759150726858 967992] L [player] [PlayerDashjs] dispatchDashEvent_: bufferStateChanged event.state bufferStalled
[1759151681652 13199] I [StreamProcessor][audio] Buffer is empty! Stalling!
[1759151681652 13199] D [BufferController][audio] Waiting for more buffer before starting playback
[1759150726858 967995] L [player] [Player] onVideoEvent_: seeked event and this.seeking_ set to false ,this.playCue_: false
[1759150726858 967996] D [player] [Player] play: (adpalyer: false)
[1759151681652 13204] I [PlaybackController] Native video element event: seeked
[1759150726858 968000] L [player] [Player] onVideoEvent: playing event this.playCue_= false
[1759151681652 13206] I [PlaybackController] Native video element event: playing
[1759150726858 968001] I [player] [Player] notifyDashBuffering: buffering, mediaType, this.dashVideoBuffering_, this.dashAudioBuffering_, this.dashAllBuffering_ false all true false true
[1759150726858 968002] L [player] [Player] isBrowserSafariMacOS: isSafariMacOS false
[1759150726858 968003] I [player] [Player] onVideoCanPlayThrough_: this.currentlyLoading_, this.buffering_ false, true

[1759151681652 13219] D [BufferController][audio] Loaded Media fragment audio with representationId: undefined and quality: undefined , data size: 33487
[1759151681652 13221] D [BufferController][audio] Append Media fragment to MSE buffer
[1759151681652 13222] D [SourceBufferSink][audio] Appending MediaSegment from period 0 to buffer. url2C2%2C%2C0%2C%2C%2C%2C%2C2%2C1%2C158997784%2CEND&st=pacoSimeSzZTjr3tndUHlLYSCleSWqM7efUf2-Yrlsk&e=MTgwMA&ts=MTc1OTE1MTY5MA, Representation: ID: 7, bitrate: 128
[1759151681652 13224] I [StreamProcessor][audio] OnFragmentLoadingCompleted for stream id 0 and media type audio - Url:/224/32urlps=1759151690407&accountinfo=ReJB+CDKbYPxVHOtlmwWN17gZHBmxpw4CsQ3vLwVOpD1NlieID7q1uu3EKQ0wRxAHmYbjbwBQAZiH4ARBGYvmdGfz7RCkjDlKIvBkRDNQcPQC8QIeqAJXbIVcchmK4h5Hy24fu9W3eE0z40pPYg4olXmLF1%2Fm73a6HVv2iMmG58%3D%3A20250929131449%3AUTC%2C%2C%2C20250929131449%2Curn%3AHuawei%3AliveTV%3AXTV4294%2C%2C-1%2C0%2C1%2C%2C%2C2%2C246%2C%2C%2C2%2C%2C0%2C%2C%2C%2C%2C2%2C1%2C158997784%2CEND&st=pacoSimeSzZTjr3tndUHlLYSCleSWqM7efUf2-Yrlsk&e=MTgwMA&ts=MTc1OTE1MTY5MA
[1759151681652 13237] D [BufferController][audio] Buffered range: 24978854.08 - 24978862.101332, currentTime = 24979122.112 `

• Have you observed a similar issue on Samsung Tizen 25 devices?

• Could you please provide guidance or recommendations for handling this scenario to ensure playback resumes correctly after seeking?

Attachments:

Full log document showing fragment requests, buffer append events, and InsufficientBufferRule triggers.

tizen2025-share.txt

Note: we cannot share the full stream, but we can provide an extract of the MPD if needed
Thank you for your help!

[bouteaupo-vo]

I am experiencing a similar issue on Tizen 25, but it only occurs on certain models, not across all Tizen 25 devices.
This behavior is not reproducible on older versions.

Here are my observations regarding currentTime and the detected gaps:

bugsnag.min.js:1 [1756715787281 41655] I [PlaybackController] Native video element event: waiting 
...
bugsnag.min.js:1 [1756715787281 42731] D [BufferController][audio] Buffered range: 25769702.005333 - 25769705.973332, currentTime =  25769702.076
...
bugsnag.min.js:1 [1756715787281 43155] I [PlaybackController] Requesting seek to time: 25753076.565)
...
bugsnag.min.js:1 [1756715787281 45911] D [BufferController][audio] Buffered range: 25753076 - 25753081.973332, currentTime =  25753076.565)
...
bugsnag.min.js:1 [1756715787281 45948] I [PlaybackController] Native video element event: seeked
bugsnag.min.js:1 [1756715787281 45949] I [PlaybackController] Native video element event: playing
...
bugsnag.min.js:1 [1756715787281 46528] D [BufferController][audio] Buffered range: 25753076 - 25753083.978666, currentTime =  25769702.076
...
bugsnag.min.js:1 [1756715787281 47269] D [BufferController][video] Buffered range: 25753076.04 - 25753092.04, currentTime =  25769702.076

After the playing event, the video continued to display for a few seconds, but the currentTime value did not progress. Also, seeking did not work as expected, the currentTime after the seeked event rolled back to the position prior to seeking.

log.txt

[dsilhavy]

Can you please try enabling enableSeekDecorrelationFix : true and check if that changes anything.

[testeur-990]

Hello @dsilhavy ,
We tested with enableSeekDecorrelationFix: true but the issue is not fixed.
What I noticed in the logs is that before the seek I have:

[audio] Buffered range: 2549170.016 - 2549172.021332, currentTime = 2549170.0845
[BufferController][video] Buffered range: 2549170.04 - 2549172.04, currentTime = 2549170.0845

Then with [PlaybackController] Requesting seek to time: 2548760.0834999997, just after I correctly get:

[BufferController][audio] Buffered range: 2548759.989333 - 2548761.994666, currentTime = 2548760.083499
[video] Buffered range: 2548760.02 - 2548762.02, currentTime = 2548760.083499

But a bit later I have:

[BufferController][audio] Buffered range: 2548759.989333 - 2548917.983999, currentTime = 2549170.0845
[BufferController][video] Buffered range: 2548760.02 - 2548840.04, currentTime = 2549170.0845

It's as if the currentTime reverted back to the position before the seek.

Please see bellow full logs

logs_to-share.txt

Do you have any idea what could cause the currentTime to revert like this? Is there any dash.js mechanism that could restore the previous position after a seek?

[dsilhavy]

Do you have any idea what could cause the currentTime to revert like this? Is there any dash.js mechanism that could restore the previous position after a seek?

That's what enableSeekDecorrelationFix is for at least for the initial seek.

I took a quick look at your logs, it looks like the seek is triggered by the platform itself and not by dash.js. The only suggestion I have right now is to enable avoidCurrentTimeRangePruning=true, not sure if it is related to the problem though.

[testeur-990]

Hello @dsilhavy
Thank you for your feedback

After further analysis, I noticed that the forced seek by the platform happens immediately after dash.js detects "Buffer is empty! Stalling!"

Questions:

• Why does Dash.js consider the buffer empty even though there are 6 s of content buffered?

• Can avoidCurrentTimeRangePruning=true prevent this stall from occurring? If the stall does not happen, the platform will have no reason to trigger its automatic seek.

• Otherwise, will we also need to adjust buffer configurations to prevent Dash.js from considering the buffer empty after a seek?

[testeur-990]

Hello @dsilhavy
After further log analysis, this Samsung platform appears to reject seeks when insufficient buffer is available at the target position.
I attempted to delay element.currentTime = currentTime until enough buffer exists. However, in my browser tests with startover streams, if I don't execute element.currentTime = currentTime (setCurrentTime), dash.js never starts downloading segments at the target position and bufferLevel stays at 0.

Could you please confirm: does dash.js need the actual seek (element.currentTime = X) to happen before it begins downloading segments at position X?