Player does not recover if license server unreachable.

[KieronAllsop]

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: Yes

Are 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)

1. Make custom asset request to a custom license server which in unreachable (for example, an invalid web application path (404 response)).
2. Enter correct path for license server.
3. Select 'Load' again.

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.

1. Stop webserver
2. Make custom asset request to custom license server (request eventually fails)
3. Start webserver
4. Select 'Load' again.

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.

[chrisfillmore]

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:

1. Load playback and force license request to fail (I'm setting error response in Charles Proxy)
2. Change Charles Proxy settings to allow license request to succeed
3. Try to load again
4. Player hangs

I traced it down to this line in DrmEngine#destroy:

var p = activeSession.session.close() || Promise.resolve();

The call to MediaKeySession#close never resolves, so Player#unload never resolves either.

[chrisfillmore]

I can also reproduce in the demo app using the same steps as @KieronAllsop described.

Edit*
It's worth pointing out that I don't see this with all content. Some of our content is able to recover through this scenario. I wonder if it's related to license server configuration.

[KieronAllsop]

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.

[TheModMaker]

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 navigator.plugins (unfortunately chrome://plugins doesn't work anymore).

[KieronAllsop]

Version of Chrome is 62.0.3202.75
Widevine Content Decryption Module - Version: 1.4.8.1029
Windows 10.15063

Navigate to https://urm.latens.com/boomplayer/demo/ (v2.2.5-debug)

Select 'Custom Asset'

• Asset = https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd
• License = https://www.random_address.com/license
  Select 'Load'

Immediate error:
"Shaka Error DRM.LICENSE_REQUEST_FAILED (shaka.util.Error { "severity": 2, "category": 1, "code": 1002, "data": [ "https://www.random_address.com/license" ], "handled": false, "message": "Shaka Error NETWORK.HTTP_ERROR (https://www.random_address.com/license)", "stack": "Error: Shaka Error NETWORK.HTTP_ERROR (https://www.random_address.com/license)\n at new shaka.util.Error (https://shaka-player-demo.appspot.com/lib/util/error.js:72:13)\n at XMLHttpRequest.xhr.onerror (https://shaka-player-demo.appspot.com/lib/net/http_plugin.js:92:14)" })"

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)

[joeyparrish]

I can't reproduce with our nightly build or the v2.2.5 official release:

https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd;license=https://www.random_address.com/license;lang=en-US

https://v2-2-5-dot-shaka-player-demo.appspot.com/demo/#asset=https://storage.googleapis.com/shaka-demo-assets/angel-one-widevine/dash.mpd;license=https://www.random_address.com/license;lang=en-US

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.

[KieronAllsop]

@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.

[joeyparrish]

I've been using Linux, but I will go retest on Windows and Mac.

[joeyparrish]

Confirmed on Mac. It definitely appears to be caused by https://crbug.com/690583, because the closed Promise on the session is never resolved. I will try to escalate the issue with Chrome team.

[chrisfillmore]

Sorry, I was on vacation and didn't respond earlier. Thanks for the update @joeyparrish!

[chrisfillmore]

@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.

[joeyparrish]

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!