Detect that Widevine CDM is revoked or incompatible

[dagwieers]

If we can detect that the used Widevine CDM is revoked, we could use this as a trigger to check for an update. (If it is not working, we can't break it by trying to update the CDM).

If we would have such a mechanism, there is no longer a need to force checking for an update on upgrade. Because potentially an update of the Widevine CDM could turn a working system in a non-working system (this has happened before).

[dagwieers]

@peak3d @emilsvennesson @mediaminister Is this at all possible?

[emilsvennesson]

I'm not sure if this data is available anywhere.

However, asciidisco/plugin.video.netflix#465 could have been avoided, at least on x86. We can start comparing the supported Widevine API version with what's supported in inputstream.adaptive. There's a hidden setting in inputstream.adaptive, WIDEVINE_API we can retrieve (although I'm not sure it's been updated, ping @peak3d) and compare with x-cdm-interface-versions that's in the manifest.json file on x86.

[dagwieers]

@emilsvennesson This PR is to track if we can implement an interface to detect this. My original idea was a service that monitors for these failures, and inputstream.adaptive would then send out specific messages for use to be used and act on.

[peak3d]

WIDEVINE_API is updated, and currently version 10 is supported.
IIRC there are manifest files shipped with widevine for some platforms where the level can be picked from. For other platforms (COS IIRC) it is not the case

[dagwieers]

@peak3d How could inputstream.adaptive get triggered if Widevine failed and an action is required?
I can foresee multiple causes:

• The Widevine CDM is no longer supported by inputstream.adaptive (e.g. Kodi 17)
• The Widevine CDM used is revoked by Widevine
• The Widevine CDM is missing or broken (corrupted, or wrong architecture)

Only in the two last cases we would be able to act (offer to upgrade, or reinstall).

[dagwieers]

I wonder where this is coming from:

2019-08-23 00:32:34.232 T:1169351536   ERROR: AddOnLog: InputStream Adaptive: Decrypt Sample returns failure!

[peak3d]

Imo too deep level for checking, danger is big that you revoke by failure

[dagwieers]

Possibly a service that checks for onPlayBackError() on Player could get more information on the failure and act accordingly if it is related to Widevine.

[dagwieers]

I finally reported this upstream at xbmc/inputstream.adaptive#497

[Sil3ntKn1ght]

id like to see widevine installed to the app directory using it, that way whatever version that stream service needs has it.
Binge crashes with the latest version but 9au and others require 4.10.2209.0, binge is only working with 4.10.1582.2, likely Binge app has a issue id imagine but a pain none the less that widevine in there independent directories would address I feel.
I am no programmer and cant code just a observation, its ironic firefox runs the older 4.10.1582.2, and all the webs stream fine with it Odd.

[dagwieers]

It happened before that Widevine has regressions. That is why we allow to roll it back and disable InputStream Helper (so you don't get updates).

[dagwieers]

@Sil3ntKn1ght Thanks for reporting this issue as separate issue #430. I pinned it at the top as this may impact more people than we expect.

[Sil3ntKn1ght]

@Sil3ntKn1ght Thanks for reporting this issue as separate issue #430. I pinned it at the top as this may impact more people than we expect.

thanks, it would seem some add-ons are more affected than others, I am on windows 10 and though I am not a coder etc I know my way around windows so in the \AppData\Roaming decided to rebuild but keep the old version buy naming it to quickly copy over parts from add-ons skin etc to save time. Binge definitely has at issue with newer Widevine on clean install test,
7Plus add-on JRMs has a issue where it wont play and after rollback of widevine it says broken, unsure how this stays affected as uninstall and reinstall add-on, even removing app data prior to install stays broken, but SlyGuys 7 is fine running older widevine however if JRM 7 add-on was installed at anytime even removed then slyguys 7 add-on won't open a stream click and nothing happens like the function is missing to click.
So i imagine there is some type of app conflict and understand that is not something of support due to nature of how those people build them.

Upon your advice I disabled the update in InputStream Helper and have atm managed to get a kodi with add-ons working.
Its odd how widevine can lead to issues causing these breaks in add-ons.
only solution was fresh build with constant back-ups and tests of each add-on.

I dont know if independent widevines in the add-on directory of those apps would work, but as the add-ons seem to all act differently it seems logical that such a method would reduce conflicts.

I certainly appreciate your help and have disable InputStream Helper, will see over the week how the streams go of my accounts.
Not a easy task for sure with what you guys do. I myself and many others are overly grateful.
I doubt my tests will help much but thought id list my methods as might help others with the issue.