Player hangs indefinitely on a multi-period mpd when skipping ahead and then behind.

[salmoro]

• What version of Shaka Player are you using?
  2.0.2

  • Can you reproduce the issue with our latest release version?
    Yes

  • Can you reproduce the issue with the latest code from master?
    Yes

• Are you using the demo app or your own custom app?
  Custom

• If custom app, can you reproduce the issue using our demo app?
  Believe so but the uniqueness of what triggers the issue needs automatic programmed navigation to reproduced consistently

• What browser and OS are you using?
  Chrome with windows 7&10 + chromium on Archlinux

• What did you do?
  Started playing at precisely the beginning of a period other than the first and then jumped back to a previous period.

• What content did you load?
  Custom MPD edited from the original "https://storage.googleapis.com/shaka-demo-assets/tos-pto-webvtt/dash.mpd" mpd, referencing its periods numerous times adding up to 70 periods and a duration of 89 minutes.

  • If standard demo asset, which one?
    N/A

  • If custom asset, what manifest and license server URIs?
    http://elchonon.com/shakarewind/1.mpd

  • How did you interact with the content, if at all?
    After experiencing this with normal rewind we've created a programmed navigation rule to consistently reproduce.

• What did you expect to happen?
  Play as normal.

• What actually happened?
  Player hangs indefinitely
  See elaborate description bellow

On a multi-period mpd, when skipping ahead and then behind (to a previous period which hasn't been loaded yet) Shaka hangs indefinitely.

Here is an example of player set to reproduce this issue.
http://elchonon.com/shakarewind/

The above player points to an MPD edited from the original "https://storage.googleapis.com/shaka-demo-assets/tos-pto-webvtt/dash.mpd" mpd, referencing its periods numerous times adding up to 70 periods and a duration of 89 minutes.

We were not able to consistently reproduce with the original mpd so we made this very long mpd with many periods which seems to be a factor in being able to consistently reproduce.

The player is Shaka compiled in debug mode, compiled 1/7/2017 from the master branch.

The player is set to begin at 421 seconds and jump back to 411 seconds and then it hangs.

We've encountered this consistently with private content of 1hr+ durations and 20+ periods and we are reproducing it here with this content.

[TheModMaker]

The problem with your custom manifest is you generated the manifest incorrectly. The first two periods should be 60 seconds and the third is 120 seconds. You have it where the second period is 120 seconds, which is causing problems.

You can see the problem by just playing the manifest from the beginning. Once it gets to 120 seconds it stops because it is still looking for more content in that period, but can't find it.

It is also possible the original issue was the same as #649. I cannot reproduce any issue with the original manifest.

[salmoro]

Thanks! Good catch there and my apologies for the bad content. It was edited by hand. Now that we corrected the MPD, the issue on the sample persists no more. Our original issue does seem similar to #649. We'll test our private content with Chrome 56 and see if that resolves it. Otherwise we'll have to figure out another way to reproduce the problem. Thanks very much for your help.

[salmoro]

Here I've managed to reproduce this

See the programmed player here:
https://dwnmi3sz90i0g.cloudfront.net/

And here is the MPD it's pointing to which plays well (beginning to end) on all Shaka versions tested (including Shaka demo player):
https://s3.amazonaws.com/aws-website-shaka-rewind-a9cdr/dash.mpd

Important Note:
We've only been able to reproduce this consistently with slower computers (i5 dual core and some quad) and with cache cleared. Not sure if this is a function of CPU or RAM (or GPU or something else)but it is important to point out that on some computers it's not possible to reproduce.

We've tried this on multiple versions of Chrome including Canary, Version 58.0.2989.0 and we're getting the same results. We've also seen this consistently on Firefox.

Here's what the player does: Begins player at 480.033 (seconds), after an initial delay of 1 seconds it repeats 5 times a rewind of 10 seconds with a 0.5 seconds delay in between. Ultimately the player gets to 7:10 (480-5x10) and will not play.

The player up above is running on shaka-player.compiled.debug.js (compiled 1/7/2017 from the master branch). So you can monitor console for errors and warnings.

Specs of computers that consistently reproduced:
-Intel i5-4210u 2.40 GHz, 8GB RAM - Windows 7-64
-Intel i5-4590 3.30 GHz, 8GB RAM - Windows 7-64
-Intel i3-m370 2.40 GHz, 4GB RAM - Windows 7-64

Specs of computer that consistently didn't reproduce:
-Intel i7-6800k 3.40 GHz, 16GB RAM - Windows 10-64

Please let me know if there's anything else you need.
Thanks

[TheModMaker]

The problem here is that Chrome doesn't seem to jump gaps after a seek. It will usually jump gaps up to 0.5 seconds, even at the beginning of playback. But if you seek to an unbuffered region that is right behind a buffered range, Chrome won't play. You just happen to seek into the <0.1 second range that is needed to cause this. You can see this by seeking to 440 and pausing, letting it buffer, then seeking to 430.05 (just before the buffered segment).

I'll have a fix up soon.

[TheModMaker]

That bug has been fixed on master. Please try again with the latest code.

[salmoro]

Thanks! Will test and confirm.

[salmoro]

TheModMaker,
On the above linked content, your fix actually worked (here it is with the latest player). Yet we have private content which still seems to maintain resembling issues.
Would it be possible for us to PM you a link to our content?
Thanks!

[TheModMaker]

Sure, my email is in CONTRIBUTORS (I'm Jacob).

[wader]

Hi, I got a similar issue to this (or #649) but at playback start. A bit randomly (more often for DRM content) shaka downloads some fragments and then gets stuck.

What seems to happen is that in shaka.media.Playhead.prototype.onWatchdogTimer_ the call shaka.media.TimeRangesUtils.bufferedAheadOf( this.video_.buffered, this.video_.currentTime); always returns 0. This is because currentTime is stuck at the same value and in bufferedAheadOf that value is less then the buffered time range start.

In onWatchdogTimer_:

> this.video_.readyState
4
> this.video_.currentTime
0.025315
> this.video_.paused
false

In bufferedAheadOf:

> b.length
1
> b.start(0)
0.08
> b.end(0)
12.08
> time
0.025315

Works fine if I reverting fb8174d where currentTime is not involved in figuring out buffered time.

This is with CEF 3.2785.1486 which I think is Chromium 53.

Could it be related to https://bugs.chromium.org/p/chromium/issues/detail?id=675556 that is mentioned in #649?

Any help would be really appreciated!

[wader]

@joeyparrish any ideas?

[joeyparrish]

@wader, try a new version of CEF (based on Chromium 56) and see if it is the same as #649. Otherwise, please file a new bug with a specific piece of content so we can reproduce your error.

[wader]

@joeyparrish Ok will try. Hopefully I can reproduce it with the CEF test app. It's a bit tricky to update CEF for the application i'm working on (API change etc).

Do you remember the reason for changing to shaka.media.TimeRangesUtils.bufferedAheadOf? should bufferedAheadOf be changed to allow to jump a small gap in the beginning if time argument is before first buffer time rage? but i'm not sure I follow why currentTime is not 0 in our case hmm. Sorry for rambling 😄

[joeyparrish]

@wader, no worries. bufferedAheadOf does some additional logic on top of just checking buffered. We use it to determine whether or not playback can continue, so we have to predict what sort of gaps the browser will be willing to jump. I'll admit, it's a little complicated, but it's because we're coping with a complicated and opaque browser behavior.

Judging from the investigation by @TheModMaker, it does not appear that bufferedAheadOf is the culprit. We'll keep you posted as we make progress.

[TheModMaker]

@salmoro I just pushed another fix that should fix the repro you sent me. Please try again.

[salmoro]

@TheModMaker
Thanks! We've been since trying the player with the most recent changes and while it has solved the immediate rewind to a previous period case, we've noticed that if we continue skipping backwards 10 seconds at a time after player stops buffering, it'll ultimately hang, usually once it gets back into an even earlier period.
Again, we had trouble reproducing on public content and it'll be easier if we can PM you a link.
Thanks very much.

[salmoro]

Is this still included in the milestone of v2.1.0?

[TheModMaker]

Sorry for the delay, just pushed a change that should fix your latest issue. These fixes will appear in v2.1, some have been cherry-picked into v2.0.x.

[salmoro]

Thanks. We're currently testing. With the latest code, so far we cannot seem to reproduce. Will confirm.

[salmoro]

Bug seems to have been fixed. TYVM!

[TheModMaker]

Glad that it is fixed. Thanks for sticking with this and providing easy reproductions.

[salmoro]

Thanks for the fantastic support.