-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preload test failure on Safari #6225
Comments
This method should be called after the load is successful, not if the load fails. This also adds a new test that ensures that onKeyStatus_ messages work correctly, as a reversion test. This was exposed by the test failures, but was not the cause of them. Issue shaka-project#6225
This exposed an unrelated bug inside the error handler in the |
The same src= content plays fine in other tests in the same suite. Testing with With seed 1, which happens to run the failing test first:
With seed 2, which happens to run the failing test second:
So the order doesn't matter and the failure is consistent. |
Adding the following logs to the error handler in lib/player.js: diff --git a/lib/player.js b/lib/player.js
index 4899b8117..feeba5849 100644
--- a/lib/player.js
+++ b/lib/player.js
@@ -6616,6 +6616,10 @@ shaka.Player = class extends shaka.util.FakeEventTarget {
// Extra error information from Chrome:
const message = this.video_.error.message;
+ const readyState = this.video_.readyState;
+ const src = this.video_.src;
+ console.log('Video error:', {code, extended, message, readyState, src});
+
return new shaka.util.Error(
shaka.util.Error.Severity.CRITICAL,
shaka.util.Error.Category.MEDIA, Produces:
So we can see that this code in the test setup isn't having the effect we expected: const actions = new Map()
// ...
.set('src-equals', async () => {
await player.attach(video, /* initMediaSource= */ false);
await player.load(SMALL_MP4_CONTENT_URI, 0, 'video/mp4');
}); |
It appears that unload() isn't being called at the proper time in Player, if at all. The old load() URI is kept alive, possibly in this.assetUri_, and recycled erroneously into video.src during src= setup. |
Something is very wrong. I'm not sure if this is broken because of preload or the pre-work to remove the load graph. The load() call for the first content is still in-progress when the call for the second content is initiated. The first content's load() sets the asset URI after the second content's load() does so. The second call should not progress until the first call is complete or canceled and an internal unload() operation has both started and completed for the first content. |
Setting a small delay in the test function goTo() prevents this bug from triggering. That means we are merely lucky that the test only fails on Safari, and that the interruption/deferment mechanisms in Player are broken in general. |
This test when run against v4.7.10 passes:
Compared to the failure in
These runs were done with browsers set to So this issue does not affect any existing release, and is likely caused by preload (which is only in |
An async operation on preloadManager in Player.load() was not using the mutex and interruption detection mechanism. I've audited load() and this was the only operation that was missing the use of the mutex. PR forthcoming. |
Interrupting load() was causing two concurrent sets of load() operations to happen at once, which led the asset URI for the second operation to be overwritten by the first. This was exposed by a test failure on Safari. There is nothing special about Safari, but the timing happened to work out such that the concurrent load() calls would intefere with each other. This fixes the issue by acquiring the mutex in load() for the preloadManager.start() operation. This issue did not affect any releases. Closes shaka-project#6225
Interrupting load() was causing two concurrent sets of load() operations to happen at once, which led the asset URI for the second operation to be overwritten by the first. This was exposed by a test failure on Safari. There is nothing special about Safari, but the timing happened to work out such that the concurrent load() calls would intefere with each other. This fixes the issue by acquiring the mutex in load() for the preloadManager.start() operation. This issue did not affect any releases. Closes #6225
Test failure in Safari:
The text was updated successfully, but these errors were encountered: