Inconsistent Chrome Stall At Discontinuities

[CeenIt]

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

What version of Shaka Player are you using?
3.0.7

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?
BOTH

If custom app, can you reproduce the issue using our demo app?
YES

What browser and OS are you using?
Chrome (Version 88.0.4324.96 (Official Build) (x86_64)) on OSX

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

MANIFEST IS:
https://media.ceen.it/c4xBB5OFBABTNFk-ceen-master-e2.m3u8

What did you do?

Just try to play the video. When it gets to the discontinuity it stalls the video for a few seconds (keeps the audio going) and then starts working again. This happens 20% of the time. If it doesn't happen, try refreshing. It never happens on Safari.

What did you expect to happen?
It shouldn't stall.

What actually happened?

It stalls the video for a few seconds (and keeps the audio going). But not everytime.

[CeenIt]

Debug info when stall happens looks like this:
shaka-player.compiled.debug.js:434 Calling switch_(), bandwidth=9985 kbps
shaka-player.compiled.debug.js:807 switch_
shaka-player.compiled.debug.js:484 Jumping forward 0.05219700000000001 seconds because of gap before start time of 0.066666
shaka-player.compiled.debug.js:567 (all): seeked: buffered seek: presentationTime=0.066666
shaka-player.compiled.debug.js:434 Calling switch_(), bandwidth=31154 kbps
shaka-player.compiled.debug.js:807 switch_
shaka-player.compiled.debug.js:580 (audio:1) buffered to end of presentation
shaka-player.compiled.debug.js:580 (video:2) buffered to end of presentation
shaka-player.compiled.debug.js:504 Stall detected at 10.099472 for 1.2269999980926514 seconds.
shaka-player.compiled.debug.js:504 Seeking forward 0.1 seconds to break stall.
shaka-player.compiled.debug.js:567 (all): seeked: buffered seek: presentationTime=10.199472

Debug info when stall doesn't happen looks like:
shaka-player.compiled.debug.js:434 Calling switch_(), bandwidth=5548 kbps
shaka-player.compiled.debug.js:807 switch_
shaka-player.compiled.debug.js:580 (audio:1) buffered to end of presentation
shaka-player.compiled.debug.js:580 (video:2) buffered to end of presentation
shaka-player.compiled.debug.js:485 Jumping forward 0.03694400000000009 seconds because of gap starting at 7.199999 and ending at 7.240179
shaka-player.compiled.debug.js:567 (all): seeked: buffered seek: presentationTime=7.240179

[CeenIt]

FYI I tried messing with:

streaming.smallGapLimit
streaming.jumpLargeGaps
streaming.stallThreshold
streaming.stallEnabled

but nothing seemed to change the behavior

[CeenIt]

Also:
https://media.ceen.it/c4xBB5OFBABTNFk-ceen-master-e1.m3u8

is basically the same except after each discontinuity there is a #EXT-X-MAP:URI

I thought maybe this was causing the issue so I removed all of these except for the initial one resulting in this manifest:
https://media.ceen.it/c4xBB5OFBABTNFk-ceen-master-e2.m3u8

but they behave the same

[CeenIt]

In case it's helpful, I cannot reproduce on iOS Safari or Chrome.

I can only reproduce on OSX Chrome and Android Chrome.

[CeenIt]

Just noticed that Chrome tools, Media Tab, Events shows a buffering event with reason: "DEMUXER_UNDERFLOW"
state: "BUFFERING_HAVE_NOTHING".
So it's possible this bug is related to:
#2566 (comment)

Which is not resolved but refers to a Chrome bug that is also not resolved. Maybe?

But I'm not sure because it still happens if I disable Chrome Hardware-accelerated video decode

[TheModMaker]

This is probably a browser bug. There is a 0.04 second gap between the discontinuities; we play through this and the browser handles jumping over it. We just play forward and the browser is not handling it well. If we were to stop before this gap and manually jump over it, the video would probably play fine; but since the browser doesn't stop for us, we'd need to manually call pause before the gap, which would require fast polling.

There is probably nothing we can do, but the discussion in #3166 is also relevant.

[joeyparrish]

Since the HLS implementation uses sequence mode since v4.0, discontinuities should not result in gaps. Closing as obsolete.