-
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
fix(preload): Set manifest before initializing DRM #7359
Conversation
@shaka-bot test |
@avelad: Lab tests started with arguments:
|
Incremental code coverage: 100.00% |
This comment was marked as resolved.
This comment was marked as resolved.
lib/player.js
Outdated
const promises = [ | ||
preloadManager.waitForFinish(), | ||
preloadManager.waitForManifest(), | ||
]; | ||
await Promise.race(promises); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder couldn't we reject manifest promise when an error occurs or is it not enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was doing that at first, but that was what was causing the test failures, I believe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this race should be moved to waitForManifest()
method then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree. Let's move it, please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, trying that out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me, but:
- I'd like @tykus160 to approve
- I'd like a PR description explaining why this is important to do in this order (e.g. what goes wrong if we don't, what benefit we get from this, etc)
Okay, I've added a description. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks! If there's an issue number associated, please add it. Otherwise, feel free to merge.
Previously, there were situations where, when handling `trackschanged` events, the manifest would not yet have been copied from the preload manager to the player. This would prevent developers from properly handling those events. This PR changes the order of operations slightly, such that the manifest is copied over earlier.
Previously, there were situations where, when handling `trackschanged` events, the manifest would not yet have been copied from the preload manager to the player. This would prevent developers from properly handling those events. This PR changes the order of operations slightly, such that the manifest is copied over earlier.
Previously, there were situations where, when handling `trackschanged` events, the manifest would not yet have been copied from the preload manager to the player. This would prevent developers from properly handling those events. This PR changes the order of operations slightly, such that the manifest is copied over earlier. Backported to v4.9.x
Previously, there were situations where, when handling
trackschanged
events, the manifest would not yet have beencopied from the preload manager to the player. This would prevent developers from properly handling those events.
This PR changes the order of operations slightly, such that the manifest is copied over earlier.