Shaka-player: Dragging Playhead to the start causes buffering forever in v3

[Benny739]

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
3.0.1

What browser and OS are you using?
Chrome on MacOs

What did you do?
Drag the playhead to the start

What did you expect to happen?
Content starts playing from the beginning

What actually happened?
Player starts buffering forever. In Version 2.5.13 everything works as expected.
This happens with Dash and HLS streams.

[joeyparrish]

Can't reproduce this with our demo content. You didn't specify any particular piece of content. Is there some specific content where this happens? Some specific version of Chrome? Does it happen in other browsers?

[Benny739]

It's not super easy to reproduce, but it happens with Chrome and Firefox.
You can see the error here: https://codepen.io/benny739/pen/GRomJWE

Jump in the middle of the stream and then drag the playhead really fast all the way to left. If you drag the playhead slowly all works as expected, the error occurs only when you drag really fast and really far. Basically you have to be quicker than the player refreshing the view.
I also recognized, when the player is buffering forever, the seeking attribute of the video element is true, like it can't find the correct position.
Fur demo purpose, I used the demo stream from the shaka homepage., but on the shaka website the error does not happen.

[joeyparrish]

I can't reproduce this on your codepen, either. If you can come up with a programmatic way to reproduce it, that might help. You can control the timing much better that way if it's a timing-dependent bug.

[Benny739]

I could not reproduce this programmatically, so I've created a video, where you can see the bug: https://youtu.be/RiNipj-A1Ng

Do you have any idea, how I can reproduce this programmatically? I tried setting the current time of the video to various values, but this works all without problems. Or maybe some other idea, how I can find out whats going on there?
This happens with Chrome and Firefox on MacOs, in Safari everything works.

[avelad]

I can reproduce it with Firefox 77 on Windows 10 seeking to the future.

[antonkro]

I can reproduce the bug on:

• Windows 10, Chrome (latest)
• Mobile (Android 10, Chrome 83.0.4103.106)

[joeyparrish]

Thanks, everyone, for the details. I've added this issue back to the triage queue. We'll take another look.

[michellezhuogg]

Hello @avelad @antonkro , would you please let us know any more specific instructions on how to reproduce the bug? Did you see it with a specific manifest? Did it occur when you seek to a specific time? Thank you!

[avelad]

Reproduced with https://storage.googleapis.com/shaka-demo-assets/sintel-mp4-only/dash.mpd seeking some times (around 300). The steps is seek to another point that in not in the buffer and seek again. It's better check it with a script.

On Firefox 77 over Windows 10

[antonkro]

Hello @avelad @antonkro , would you please let us know any more specific instructions on how to reproduce the bug? Did you see it with a specific manifest? Did it occur when you seek to a specific time? Thank you!

We are generating it with bento4. But it also appears in the codepen example.
I'm doing the following:

1. Jump somewhere into the video
2. Dragging the player cursor (a little bit faster) backwards
3. Drop cursor, now its buffering infinite

Cheers Toni

[joeyparrish]

I tried reproducing this in v3.0.1 as specified in the original report, but I haven't been able to.

https://v3-0-1-dot-shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/sintel-mp4-only/dash.mpd

I've also tried in v3.0.3 (latest release) with no success.

I've only tried so far on ChromeOS 84 (stable channel), but not on the platforms in the report so far:

• Chrome on Mac
• Chrome on Windows
• Chrome on Android
• Firefox on Windows
• Firefox on Mac

The only OS I have local access to at home is ChromeOS.

Before I start debugging over VNC on Windows or Mac, is anyone else still able to reproduce the issue? It would be especially helpful if you would try in the latest v3.0.3 release in case we've fixed it already.

[shaka-bot]

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

[Benny739]

@shaka-bot reopen
I have tested again with 3.0.4 all on MacOs:

• chrome - not working
• firefox - working
• safari - working

The interesting thing is the same stream is playing without any errors on the shaka demo page, but produced the buffering error in this codepen: https://codepen.io/benny739/pen/GRomJWE
And the demo page without any errors: https://v3-0-1-dot-shaka-player-demo.appspot.com/demo/#audiolang=de-DE;textlang=de-DE;uilang=de-DE;asset=https://storage.googleapis.com/shaka-demo-assets/sintel-mp4-only/dash.mpd;panel=HOME;build=uncompiled

[antonkro]

Hi,

here a small screen capture hopes this helps seeing what its going wrong hope this helps.

My Chrome Version: Version 85.0.4183.102 (Official Build) (64-bit)

https://www.loom.com/share/7244a166cfc34dc8a77f04bd0fadfae0

[joeyparrish]

The video was very helpful. And I can reproduce it on your codepen (using native video controls) but not in our demo (using our UI controls).

I also haven't managed to reproduce it yet using our demo with native video controls. I'm not sure if that's significant, or if the page layout is also a factor.

When the issue occurs in the codepen, I see that the buffered ranges for audio and video are very different. Video is buffered from roughly 0 - 12, and audio is buffered from 200-something. The value of video.currentTime before I started seeking was in the 500s, so the audio buffered range makes no sense. I'm not sure what this means. I didn't get any logs from the codepen repro.

[joeyparrish]

Also, it does not seem to be reproducible with programmatic seeking, such as video.currentTime = 0 in the console. This leads me to believe that it's something specific to dragging the playhead on the native controls. It's possible that we get hit with many rapid seek events, and that some race condition results in our buffering at the wrong place.

[Benny739]

Version 2.5.x works perfectly, the error started with version 3. Maybe this helps.

[joeyparrish]

Here's a programmatic way to reproduce the issue, which is probably further evidence for seek event spam being the cause:

function hack() {
  video.currentTime -= 70;
  console.log('seek', video.currentTime);
  if (video.currentTime > 0) { setTimeout(hack, 1); }
}
video.currentTime = 500;
setTimeout(hack, 10 * 1000);

When the issue is triggered, player.getBufferedInfo() will show you video buffering at 0, and audio buffering from another position. I don't know how often it can be triggered with this method, but so far, for me, it's more often than not.

[joeyparrish]

Oh, and I should have mentioned, that this method makes the issue reproducible with our demo.

[joeyparrish]

When the first seek happens, the video buffer is being updated, so we defer clearing the buffer. The audio buffer is cleared right away. Then an audio segment gets fetched from a point somewhere in the middle, after the first couple rapid seeks. The rapid seeks must then complete before the audio segment gets fetched. When the seek is handled, StreamingEngine sees that nothing is in buffer yet for audio, so it does nothing, even though there is a fetch in progress.

We should make these unbuffered seeks abort all in-progress operations, so that there isn't a race between seeking and fetching segments.

[antonkro]

Amazing thanks for the Help :)

[joeyparrish]

I have a fix that is working for me in manual tests. I need to update the automated tests, add a new one if needed to cover this case, and get the change reviewed by the team. But I feel confident that this will be fixed in our next release.