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

Invalid config type when stopping casting #1716

Closed
TheModMaker opened this issue Nov 30, 2018 · 0 comments
Closed

Invalid config type when stopping casting #1716

TheModMaker opened this issue Nov 30, 2018 · 0 comments
Assignees
Labels
flag: Why didn't we catch this sooner This issue is embarassing; we may still need an automated test that could have prevented this issue status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@TheModMaker
Copy link
Contributor

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

What version of Shaka Player are you using?:
master (>v2.5.0-beta2 2f1337d)

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?:
Demo

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

What browser and OS are you using?:
Chrome for Mac

What are the manifest and license server URIs?:
Any encrypted asset (tested with Axinom Multi-DRM asset).

What did you do?
Start casting an encrypted asset. Stop casting while playing.

What did you expect to happen?
No errors when resuming local playback.

What actually happened?
Several error logs like Invalid config, wrong type for .drm.advanced.com.widevine.alpha.serverCertificate. It looks like getConfiguration from the Chromecast gives us a generic object instead of null or a Uint8Array for the server certificate.

@TheModMaker TheModMaker added type: bug Something isn't working correctly flag: Why didn't we catch this sooner This issue is embarassing; we may still need an automated test that could have prevented this issue labels Nov 30, 2018
@TheModMaker TheModMaker added this to the v2.5 milestone Nov 30, 2018
@theodab theodab self-assigned this Jan 17, 2019
joeyparrish pushed a commit that referenced this issue Jan 22, 2019
Using JSON.stringify and JSON.parse turns Uint8Arrays into generic
objects, but we need them to be actually be Uint8Arrays.
This adds a special case to CastUtil.serialize and CastUtils.deserialize
to preserve the object type of Uint8Arrays.

Closes #1716

Change-Id: I370711c016c5d5ba21cdbccb3d970c6e074a3edd
@shaka-project shaka-project locked and limited conversation to collaborators Mar 23, 2019
@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
flag: Why didn't we catch this sooner This issue is embarassing; we may still need an automated test that could have prevented this issue status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

3 participants