Skip to content
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

Emit error when the wrong keys are retrieved #301

Closed
joeyparrish opened this issue Mar 7, 2016 · 3 comments
Closed

Emit error when the wrong keys are retrieved #301

joeyparrish opened this issue Mar 7, 2016 · 3 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone

Comments

@joeyparrish
Copy link
Member

We don't currently detect if the wrong keys are retrieved. In this scenario, a license has been requested and retrieved, but the license does not contain the keys that the browser needs to decode the content.

We could detect this in many cases and emit an error. During integration and debugging, this would help point out issues with the license server/proxy.

@joeyparrish joeyparrish added the type: enhancement New feature or request label Mar 7, 2016
@joeyparrish joeyparrish self-assigned this Mar 7, 2016
@joeyparrish joeyparrish added this to the v2.0.0 milestone Mar 7, 2016
@joeyparrish
Copy link
Member Author

I believe this would involve two events, waitingforkey and canplay, to enter and exit the "waiting on keys" state, respectively. Needs investigation to confirm.

@ddorwin
Copy link

ddorwin commented Mar 11, 2016

Do you want to detect the wrong key based on ID or the actual key? In the latter case, you may just get a decode error.

@joeyparrish
Copy link
Member Author

We're already able to detect decode errors, but in cases where we have the wrong key IDs for the content, we currently just wait forever. This happens sometimes during early app development due to mistakes in the player configuration or the license server.

If we can detect this, we can save people debugging time and effort.

@joeyparrish joeyparrish removed their assignment Apr 6, 2016
@TheModMaker TheModMaker self-assigned this Apr 7, 2016
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants