-
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
Player does not recover if license server unreachable. #1093
Comments
I think I'm having the same issue, and I feel like it's new because I've never noticed it before. I haven't gotten around to thoroughly testing yet. @KieronAllsop are you seeing this in Firefox too? I have only tested in Chrome and that made me think it was a Chrome bug because of the particular behaviour. I will try to test in other browsers. Here's what's happening to me:
I traced it down to this line in
The call to |
I can also reproduce in the demo app using the same steps as @KieronAllsop described. Edit* |
Yes it occurs in both Firefox and Chrome, but not in Edge with the same steps so must at some level be related to Widevine ? In response to your thought @chrisfillmore that it could be related to license server configuration, neither the first play request, which causes the hang, nor the second play request ever reach the license server. |
This looks similar to https://crbug.com/690583. But I cannot reproduce. I went to the hosted demo and entered one of the protected demo asset URLs into the custom asset field and used a bad URL for the license server. I get an error and the video stops at the end of the clear lead. If I select a different asset and click Load again, the new asset plays fine. Can you reproduce with just the hosted demo without an external proxy? Can you provide a manifest URL to a content that reproduces? What is the exact version of Chrome you are using? What version of the Widevine plugin are you using? You can get it from |
Version of Chrome is 62.0.3202.75 Navigate to https://urm.latens.com/boomplayer/demo/ (v2.2.5-debug) Select 'Custom Asset'
Immediate error: Clear lead plays, then video stops. If I go to drop down and select a different asset (clear or widevine) nothing happens when I select 'Load' I must reload page to get anything to play again. Does the same in iOS Sierra 10.12.6 (Chrome and Widevine versions the same) |
I can't reproduce with our nightly build or the v2.2.5 official release: In both cases, the first video stops after the clear lead. If I select another video from the list and click "Load", it loads. I am also unable to reproduce in your demo app: https://urm.latens.com/boomplayer/demo/ I am running the same Chrome and Widevine versions as you. |
@joeyparrish can I ask what operating system you are running Chrome on? I agree the issue is not reproducible in linux (Fedora 25 specifically). However having tried both links given above and the same version of Chrome/Widevine I can reproduce the issue on our Windows 10 (v15063), Windows 10 Insiders (v17025), High Sierra and Sierra test machines. |
I've been using Linux, but I will go retest on Windows and Mac. |
Confirmed on Mac. It definitely appears to be caused by https://crbug.com/690583, because the |
Sorry, I was on vacation and didn't respond earlier. Thanks for the update @joeyparrish! |
This is a workaround for Chrome bug https://crbug.com/690583. Resolves shaka-project#1093
@joeyparrish would Shaka team consider this workaround? #1168 I've deployed a fork of Shaka in our projects which uses this workaround, and haven't encountered any issues in the wild (that I know of). In general I prefer not to maintain a fork though. |
This is a workaround for Chrome bug https://crbug.com/690583 Resolves #1093
The bug in Chrome is still not fixed, but the workaround by @chrisfillmore will appear in the v2.2.8 bug fix release of Shaka Player. Thanks! |
This is a workaround for Chrome bug https://crbug.com/690583 Resolves #1093
An improved workaround for https://crbug.com/690583 and #1093, on top of PR #1168. If we don't wait at all, we end up trying to use the same session ID too quickly, which causes a playback failure. Change-Id: I8c9d1a0f09432054b862e033b80b0c2f47739c74
An improved workaround for https://crbug.com/690583 and #1093, on top of PR #1168. If we don't wait at all, we end up trying to use the same session ID too quickly, which causes a playback failure. Change-Id: I8c9d1a0f09432054b862e033b80b0c2f47739c74
Have you read the FAQ and checked for duplicate issues: Yes
What version of Shaka Player are you using: 2.2.4
Can you reproduce the issue with our latest release version: Yes
Can you reproduce the issue with the latest code from
master
: YesAre you using the demo app or your own custom app: Custom App
If custom app, can you reproduce the issue using our demo app: Yes
What browser and OS are you using: Chrome 62 / Firefox 56
What are the manifest and license server URIs:
(you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest) Emailed
What did you do?
First scenario: (to easily demonstrated the issue)
Second scenario: (which is the most likely issue in deployment, e.g. where the license server is unreachable) can be demonstrated by doing the following.
What did you expect to happen?
The first request will give a NETWORK ERROR.
The second request will hit the license server and serve a license or give an expected error.
It is not expected that the player application should need reloaded.
What actually happened?
The first request give a NETWORK ERROR.
The second request is not made as the player appears to have frozen.
To make the second request the page must be reloaded.
The text was updated successfully, but these errors were encountered: