Playback stalled after using a "skip back" feature

[riksagar]

I'm looking at an issue on a 2018 LG TV. I suspect it's related to "buffer trimming" by the OS when there's more data in the SourceBuffers than memory allows (the OS had to reclaim some resources). I guess it could be Shaka doing an explicit remove()?

The problem is happening when I use a "skip back" button in our UI. You know the type of "quick review" feature that seeks back something like 30 seconds when you want to quickly repeat what just played.

What I'm seeing is that playback jumps back as expected, and plays OK for a short time, but then playback stops. In the logs, I see a "waiting" event from the video element because there's no buffered data at currentTime.

When it happens playback doesn't resume. To recover we must quit the player and restart.

It's an intermittent issue, but here's what I've extracted from logs for one instance when it happened:

• seeking event (to time 1549.57)
• seeked event (currentTime reports 1549.57)
• canplay, play, playing events (currentTime reports 1549.57)
• checking buffered ranges on video element reports 1549.505044 => 1576
• progress event
• Shaka log message reports: "Ignoring large gap at 1549.546 size 10.970043999999916"
• 3 seconds after the "playing" event I see a "waiting" event
  • currentTime at that instant reports a time of 1552.549
  • checking buffered ranges of video element reports 1560.516044 => 1576

IMO, this is primarily an issue with the underlying webOS player pipeline. It appears to be making poor choices when it comes to choosing data to discard! However, I'm wondering if you'd expect Shaka to attempt to reload data around the video element's currentTime when this type of "buffer trimming" occurs on resource limited devices.

[TheModMaker]

I think I see the bug. When we do an append, we cache the video's current time and pass that around. As part of the append, we evict data behind the playhead according to streaming.bufferBehind configuration. We do the eviction based on the cached current time and after we fetch the segment.

So it is possible that, while downloading the segment, we seek backward. The seek happens immediately and we detect it as a buffered seek and do nothing. Then after the download is done, we evict based on the old time. This evicts the time around the current time and we don't re-download those segments.

You could work around this by setting streaming.jumpLargeGaps to true, but that will just cause us to jump ahead again and basically ignore your seek backwards.

[TheModMaker]

This is actually fairly easy to reproduce on Chrome on desktop. Just start in the middle of the video and use video.currentTime -= 3 in DevTools several times. It works better on a slower connection so the video buffers.

[TheModMaker]

I am able to reproduce fairly easily with v3.1.1, but cannot reproduce on the latest release (v3.2.1). Can you try with the latest version to see if it has been fixed?

[avelad]

Can you test with v4.3.3? Thanks!

[github-actions]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.