The playback get stuck after replay

[yairans]

Have you read the FAQ and checked for duplicate issues: Yes

Are you using the demo app or your own custom app: demo app

What browser and OS are you using: Chrome 60 on MacOS Sierra 10.12

What are the manifest and license server URIs:
https://qa-nginx-vod.dev.kaltura.com/dash/p/1091/sp/109100/serveFlavor/entryId/0_wifqaipd/v/2/flavorId/0_,m131krws,5407xm9j,xcrwyk2n,ep7yqavp,1xcr8gnf,kozg4x1x,njhnv6na,/forceproxy/true/name/a.mp4.urlset/manifest.mpd

What did you do?
Play -> seek to close to end -> play the rest until the end -> replay -> seek to close to end -> play the rest

What did you expect to happen?
The playback should continue until the end and then the play button should appear

What actually happened?
The player get stuck at ~12.20 position

[joeyparrish]

@yairans, what version of Shaka Player are you using? Can you reproduce with the latest code from master?

[yairans]

@joeyparrish
I'm using the latest demo app version 2.1.7-debug.
I can reproduce it also with the latest of master.
Thanks.

[joeyparrish]

Thank you for the detailed steps to reproduce. This was very helpful.

In my repro, I load the content, seek to 12 minutes (video.currentTime = 12 * 60), play to the end, then click play again, seek to 12 minutes again, and it does indeed get stuck at 12:20.

[joeyparrish]

When playback gets stuck, the state of streaming is:

mediaStates = shakaDemo.localPlayer_.streamingEngine_.mediaStates_
{audio: {…}, video: {…}, text: {…}}
video.duration
741.08111
video.currentTime
740.634431
video.duration - video.currentTime
0.44667900000001737
mediaStates.audio.lastSegmentReference.endTime
744
mediaStates.video.lastSegmentReference.endTime
744
mediaStates.text.lastSegmentReference.endTime
741.081
mediaStates.audio.lastSegmentReference.updateTimer
undefined
mediaStates.audio.updateTimer
null
mediaStates.video.updateTimer
null
mediaStates.text.updateTimer
3047

We're stuck 0.44 seconds before the end of the stream, video and audio segments extend past the end of the presentation, text fills the duration exactly, and text is still trying to update for some reason.

[joeyparrish]

Even clearer indication:

mediaStates.text.endOfStream
false
mediaStates.video.endOfStream
true
mediaStates.audio.endOfStream
true

[joeyparrish]

If I artificially increase the text stream duration slightly (+1 second), the problem does not occur. Not a fix, just another data point.

[joeyparrish]

Seems to be cause by a fudge factor introduced in c2dc1d8. The extra value added to the append window, combined with your video & audio segments extending past the nominal presentation duration, results in the video duration increasing slightly after the first end-of-stream event. After this, the text stream is no longer long enough to fill the duration.

This hack was introduced to avoid tiny, tiny gaps in multi-period playbacks, which should no longer be needed now that we have gap jumping.

[joeyparrish]

The fix is in master now and will be cherry-picked to v2.2.2.

[OrenMe]

Hi @joeyparrish, do you know when 2.2.2 will be tagged? seems like nothing has been added to 2.2.x branch since this fix so hoping you can tag a patch version.
Thanks.

[joeyparrish]

@OrenMe, I'm working on it now, and I hope to release this week. We had a small problem that prevented us from doing a release sooner, and that was fixed yesterday in 3a91c46.

[OrenMe]

Thanks @joeyparrish

[yairans]

@joeyparrish Please reopen.
Still reproduced on Edge/IE11.

[joeyparrish]

Reopened. We'll try to look into it again.

[joeyparrish]

We have decided to limit seeking to duration. When a user seeks to a time >= duration (or selects a playback start time >= duration), we will seek to some fixed distance before the duration instead.

This seems to be the only consistent cross-browser solution, and it is consistent with behavior we have seen in other applications.

[OrenMe]

Hi @joeyparrish, I'm not sure I follow how this is related to the issue?

[joeyparrish]

Sorry, I believe this is related to #1014, but I could be wrong. I expect my fix for #1014 will fix this as well.
I'll be verifying my assumptions soon, and I will report back.

[joeyparrish]

[UPDATE]: Nightly repro URL fixed

I was wrong. The two issues are unrelated.

I am unable to reproduce this issue on Chrome or IE with the latest nightly build:
https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://qa-nginx-vod.dev.kaltura.com/dash/p/1091/sp/109100/serveFlavor/entryId/0_wifqaipd/v/2/flavorId/0_,m131krws,5407xm9j,xcrwyk2n,ep7yqavp,1xcr8gnf,kozg4x1x,njhnv6na,/forceproxy/true/name/a.mp4.urlset/manifest.mpd;lang=en-US;play

In both cases, I start the video, seek to around 11:30, let it play to the end (12:21), then click play again, let it start over at 0, seek to around 11:30, then let it play to the end again. On both Chrome and IE, the video reaches the end (12:21).

I find that on Chrome, when the video reaches the end state, the demo controls show the giant "play" button over the video frame. On IE, the demo controls remain in a "playing" state. To replay the video on Chrome, I click the giant play button. To replay the video on IE, I first click the "pause" button, then "play". This seems to be a bug in the demo controls on IE. I will investigate this.

In the mean time, please confirm that the original bug (stuck at 12:20) has already been fixed.

[joeyparrish]

I fixed the video controls bug and pushed an update to the nightly build on appspot. Please take a look and confirm. Thanks!

[joeyparrish]

The fix has been cherry-picked for v2.2.8.

[yairans]

@joeyparrish
Confirmed. it's working ok in the nightly link above (excluding the controls bug).
Thanks.

[yairans]

@joeyparrish
please reopen this issue.
Reproduced on ie11+win8 with v2.3.2.
Regression from v2.2.8

[yairans]

@joeyparrish
Actually it reproduced with v2.2.8 as well
console.log

[joeyparrish]

We'll take a look. Thanks!

[joeyparrish]

Repro Steps:

1. Open https://shaka-player-demo.appspot.com/demo/#asset=https://qa-nginx-vod.dev.kaltura.com/dash/p/1091/sp/109100/serveFlavor/entryId/0_wifqaipd/v/2/flavorId/0_,m131krws,5407xm9j,xcrwyk2n,ep7yqavp,1xcr8gnf,kozg4x1x,njhnv6na,/forceproxy/true/name/a.mp4.urlset/manifest.mpd;lang=en-US;build=uncompiled;play
2. Seek close to the end (11:50)
3. Play to the end (12:21)
4. Hit the giant "play" button to replay
5. Seek close to the end again (11:50)
6. Play to the end (12:21)

At step 4, in v2.3.2 on IE 11 specifically, the giant play arrow does not show up. Investigation shows that the arrow only shows when the video is paused. On IE, video.ended == true, but video.paused == false, which is not the way other browsers behave. Normally, video.ended implies video.paused.

As a fix, we will have to check both video.ended and video.paused. Note that this only affects our custom controls in the demo app, and nothing is broken in the Shaka Player library itself.

[joeyparrish]

After fixing the issue in the demo controls at step 4, another issue surfaces, and the video gets stuck in a buffering state at 12:20, as in the original issue. Not sure about the cause yet.

[joeyparrish]

After the first playback ends, MediaSource on IE 11 grows the duration from 741.081 to 741.081111. This rounding error is causing the buffering at the end of replay.

[joeyparrish]

The chain of bad data goes from MediaSourceEngine.getDuration() to PresentationTimeline.setDuration() to PresentationTimeline.getDuration() to StreamingEngine.update_(), which prevents a call to MediaSourceEngine.endOfStream(), which affects the state of MediaSourceEngine.ended(), which affects PlayheadObserver's buffering state calculations.

[joeyparrish]

We should be able to fix this in v2.3.3.

[joeyparrish]

Cherry-picked for v2.3.3.