MANIFEST.RESTRICTIONS_CANNOT_BE_MET error yet playback continues

[TheJohnBowers]

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

MANIFEST.RESTRICTIONS_CANNOT_BE_MET.har.zip

What version of Shaka Player are you using?:
Shaka Player v2.4.3-uncompiled -- From the public appspot demo

Can you reproduce the issue with our latest release version?:
Yes

Can you reproduce the issue with the latest code from master?:
I haven't tried

Are you using the demo app or your own custom app?:
Demo App

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

What browser and OS are you using?:
Chrome Chrome (68.0.3440.91) on Android (Samsung Galaxy S8)
I am not really sure that this is exactly necessary to reproduce, but HDCP and security level restrictions are being enforced such that HW_SECURE_ALL is required for video.

What are the manifest and license server URIs?:
Live Dash Manifest

https://shaka-player-demo.appspot.com/demo/#asset=https://content.uplynk.com/channel/3ff06a21737f40bd9f0e3bc342a4ca6b.mpd?expand=hdcp_ndo_video_sl5;license=https://content.uplynk.com/wv;lang=en-US;videoRobustness=HW_SECURE_ALL;audioRobustness=SW_SECURE_CRYPTO;build=uncompiled

What did you do?
Play the above URL several times (load/unload). Eventually I will hit an instance where "Shaka Error MANIFEST.RESTRICTIONS_CANNOT_BE_MET() pops up" -- AND then the video plays with the error message over the top. Nothing obviously bad is happening the licenses and manifests are returning properly, and indeed the video plays -- But people that I have testing my license restrictions think there is something wrong. I feel like this error might be triggered on a slower response from the license server but I am not really sure what causes it.

What did you expect to happen?
I would not ever expect to see this error when I successfully play.

What actually happened?
Error message and playback -- See the attached screenshot and .har

[joeyparrish]

I'll look into it. Thanks!

[joeyparrish]

I managed to reproduce this with the latest code. What I'm seeing is that Shaka Player thinks that we don't have the necessary keys. It complains that key ID 3c452c3a37844ebfbc50c736761c8930 is missing.

Repro notes for anyone else working on this: It's very inconsistent, and difficult to reproduce. It doesn't require rapid load/unload, and it seems to reproduce within 10-15 tries.

[joeyparrish]

In a failure case, the filtering in shaka.Player.prototype.checkRestrictedVariants_ runs several times without any key statuses. Then it runs with one key ID, that of the audio track. This is when the error is triggered, since we have no keys for video. Then it runs again with all three keys (audio key + 2 video keys).

So this seems to be a race in licensing somehow. Still digging.

[joeyparrish]

There seems to be a race in the player. If the licenses come in slightly apart, then some other event can trigger a restrictions check while we only know about some of the keys.

In my most recent repro, the timing between the two licenses is only 1 second.

[joeyparrish]

Two main problems:

1. DrmEngine batches up key statuses to avoid this problem, but it only waits 0.5 seconds. In some cases, that's not long enough.
2. There appears to be a loophole: Player can pull key statuses from DrmEngine directly without waiting for an event. So other events can trigger a restrictions check using the latest key statuses, which may still be in the process of "batching up".

[joeyparrish]

Correction: DrmEngine batches up statuses to avoid a different problem.

The fix will be to close the loophole to avoid the player seeing incomplete data, and to delay sending key statuses to the player until all sessions have been updated.

[joeyparrish]

The fix is in master now. If you're waiting for a release, it should appear in v2.4.4 and v2.5.0.