Shaka Player is not able to resume live streaming after network problems

[wkuranowski]

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

What version of Shaka Player are you using?: 2.3.5

Can you reproduce the issue with our latest release version?: yes

Can you reproduce the issue with the latest code from master?: didn't test

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

What browser and OS are you using?: Windows 10 / Chrome 65

What are the manifest and license server URIs?:
https://v2-3-5-dot-shaka-player-demo.appspot.com/demo/#asset=//wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mpm4sav_mvtime.mpd;lang=pl;logtoscreen;build=uncompiled

What did you do?

1. Play the stream
2. Press F12 and add a new network throttling profile (1kb/s up & down, 1000 ms latency) on the network tab and enable that profile.
3. Wait for about 2 minutes and switch network throttling profile to Online.

What did you expect to happen?
Stream should start to play with no issues.

What actually happened?
Stream starts to play after a very long delay. Then after a few moments, there are a lot of glitches / buffering / etc.

Works fine with version 2.3.2 and below:
https://v2-3-2-dot-shaka-player-demo.appspot.com/demo/#asset=//wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mpm4sav_mvtime.mpd;lang=pl;logtoscreen;build=uncompiled

[joeyparrish]

Confirmed. I will see what I can figure out about this. First I will try to determine if it is content-specific.

[joeyparrish]

I am unable to reproduce with this stream, which is interesting:

https://v2-3-5-dot-shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-live-assets/player-source.mpd;lang=pl;build=uncompiled

Not sure what that means yet. That stream has a much longer seek range (15 minutes vs 30 seconds), but that may be irrelevant. In both cases, the playhead gets bumped back into the seek range as it falls out during buffering, as it is meant to.

It may be time to bisect the source between v2.3.2 and v2.3.5 to find the specific commit that caused this change in behavior. Since my other analysis hasn't turned up anything useful, a bisect may be the best way to understand what is going wrong.

[wkuranowski]

I can tell you that problem appeared in 2.3.3.

[joeyparrish]

Thank you! We'll try to narrow it down further.

[TheModMaker]

I believe this is caused by 2597150, which tries to ensure we don't update the manifest too often on bad connections. Because the one manifest request takes so long while we are throttled, we think the network is slow and we delay how often we update the manifest.

[wkuranowski]

So it seems that the lowest frequency of manifest downloading should not be lower than what is needed for smooth playback of a given stream.

[TheModMaker]

There is no way to know how often we need to update the manifest. Sometimes we can wait 20 seconds between updates, sometimes we need to update every 2 seconds. That is why the minimumUpdatePeriod property exists. But on slow devices/networks, we don't want to update too often.

That commit was only added in v2.3.5, so it couldn't be a problem in older versions. I am seeing different behavior with different versions, can you confirm this is what you are seeing.

Repro steps:

1. Navigate to page.
2. Click "Load"
3. Wait a few seconds, then throttle network connection
4. Wait 60 seconds
5. Un-throttle connection

In v2.3.5 I am seeing the seek bar repeatedly jump back into the seek window while we are throttled. Once we un-throttle, we start playing eventually, but then sometimes stall again.

In v2.3.3 and v2.3.4 I am seeing an initial seek to keep us in the seek window, but then we stay at the left of the seek window after that. Then once we un-throttle the connection, there is a log of Ignoring large gap of XXX and the video buffers but doesn't play. If I manually seek back into the seek window, the video plays fine.

In v2.3.2 I see us repeatedly seek back into the seek window and once we un-throttle, the video plays fine.

Is this what you are seeing?

[wkuranowski]

Yes, this is exactly what I am seeing.

Is it possible to use the duration of content in manifest to determine the lowest refresh frequency of the manifest?

[joeyparrish]

Fix cherry-picked to v2.3.7