Rapid seeking causing error 5000

[BucherTomas]

Both the default test content provided by Shaka and our own custom content exhibit a problem when starting playback and then very rapidly seeking randomly back and forth by clicking on the seekbar. Sometimes the error manifests after 5 seeks, sometimes it takes 50-100, it's very random.

I am aware that this scenario would not be very common during normal usage, however, I am reporting this, because the error is not resolvable. Once it occurs, any attempt to seek elsewhere, pause or play the video again does not have any impact. The content needs to be reloaded.

In our testing, the error is usually complaining about the buffer state of audio track, occasionally it concerns video track, though.

Please see the attached screenshot. The Big Buck Bunny video is run from our own Wowza server, because the one provided by Shaka does not start at all with error 5002. Content created with Bento4 packager has the same seeking problems, so it does not appear that streaming or packaging technology is the culprit.

Thanks Tomas

[BucherTomas]

Additional info:

• error 5000 replicable during fast seeking with all available browsers in Win 8.1, namely Chrome 49, Firefox 45, Opera 36 and IE 11.
• Shaka 1.6.5 is stable in this regard

[joeyparrish]

Thanks, we'll take a look.

[tdrews]

Hi, we just landed d2a812c, which changes some of the internal streaming logic. Can you try again from master?

[BucherTomas]

Yes, now it appears to be okay, thanks a lot. There is one new cosmetic issue in the console logs related to this.

If you very quickly seek a couple of times

Chrome reports: undefined:1 Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().

Firefox reports: expected performingUpdate to be true on line 479 in /lib/media/streaming_engine.js

Playback is not affected, though.

[tdrews]

Great, thanks for testing. We'll take a look at those remaining issues.

[tdrews]

I'm having a bit of trouble reproducing the issue. Does it only occur on Windows 8.1? Should I just keep clicking randomly around the seek bar until the error occurs? Which piece of default content can you reproduce with? Thanks.

[BucherTomas]

Since IE, Firefox and Opera do not report the DOM exception, I concluded that it must be something influenced by the browser itself. This seems to support it https://bugs.chromium.org/p/chromium/issues/detail?id=593273 It's caused by recent updates, so if you have an older version of Chrome, you wouldn't be able to reproduce it.

That "expected performingUpdate to be true" message seems to be caused by high bitrate content. Our own 4k and default Sintel 4k sample cause this during fast seeking and it is reproducible in all browsers.

[tdrews]

Yes, I see the DOMException error now; it certainly looks like a browser issue. I've also determined that the assertion failure is a false-positive: if a user seeks while a segment is being appended and then again immediately after that segment is appended (but before another segment is fetched), waitingToClearBuffer will be true and performingUpdate will be false. So, that assertion is invalid. We'll have a patch up shortly to just remove that assertion.

[patrickkunka]

Could anyone shed some light on what error 5000 is? We've been seing it come in quite a bit in our error reporting recently (widevine encrypted videos), but it doesn't seem to be documented in the JSDoc errors class page.

[joeyparrish]

Error code 5000 was removed between v2.0.0-beta2 and v2.0.0-beta3. Here are the docs from beta2:

http://v2-0-0-beta2.shaka-player-demo.appspot.com/docs/api/shaka.util.Error.html

5000 is INCONSISTENT_BUFFER_STATE, which no longer exists because we simplified away that possibility in 6daa7f3.

If you're getting that error, you're definitely running either beta or beta2. We've fixed a lot of bugs on the way to v2.0.0, so please upgrade when you have the chance. Please note the small API changes introduced between beta2 and beta3, which are noted in CHANGELOG.md.

[patrickkunka]

OK - thanks a lot for the information, we'll upgrade ASAP.