HLS Event Playlist: Getting QUOTA_EXCEEDED_ERROR when seek to a different position

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

What version of Shaka Player are you using? 2.5.4

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? Tried both

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

What browser and OS are you using? Chrome 76 MacOS 10.14, But reproducible in other platforms as well

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

What are the manifest and license server URIs?

Unfortunately, I can’t share this stream publicly 😦 Note: Stream is working fine in other players.

What did you do?

Tried playing an HLS event playlist, and seeked backward to a different position.

What did you expect to happen? The content should play.

What actually happened?

Shaka kept downloading and appending segments to the buffer, eventually got a QUOTA_EXCEEDED_ERROR. I tried debugging the issue. Few observations,

1. The source buffer is not triggering any error on appendBuffer
2. bufferedAhead and SourceBuffer.buffered remained 0 hence the streaming engine kept requesting for new segments.
3. If I update child manifest with #EXT-X-PLAYLIST-TYPE:VOD, it’ll work fine
4. handleQuotaExceeded_ method in streaming_engine is working as expected

[theodab]

After much investigation, it is looking like this is a problem with mux.js, the tool that we use to turn ts content into mp4 content for platforms that do not support ts. For whatever reason, if you perform an unbuffered seek backwards with multiplexed ts content, the resulting mp4 outputs will start having empty audio tracks. This causes MediaSource to not register the output as being within a buffered range, and thus we keep buffering further and further ahead until we go past our quota. This also means that, if you perform a very short unbuffered seek, such that it doesn’t go over the quota, it will successfully start playing again, but without audio.

I have filed an issue for this on the github page for mux.js: https://github.com/videojs/mux.js/issues/312 You can track the progress of that bug there.

In the meantime, we can theoretically fix this by tearing down and re-creating the transmuxer between each operation. That seems like a very inefficient solution, however, so I’m not sure if it would be a good idea to implement.

[joeyparrish]

Closing this stale external (non-Shaka) issue. If you disagree, please reply with @shaka-bot reopen, and it will be automatically reopened.

Also, I’m reasonably sure this was fixed in today’s 5.5.3 release of mux.js.