Request to better manage case of failed widevine update for Linux ARM

[CastagnaIT]

Several times it has happened that users go crazy when a widevine update is automatically performed with a different architecture than ARM, and i know that the wv library search cannot always be perfect

this rightly breaks all addons that need this library, but the problem is that users never know what to do and they open multiple Issue requests everywhere

i have noticed that the "ldd" command in inputstreamhelper always fails when this problem happen

My suggestion are:

• Use the "ldd" command to check if the downloaded library is compatible with the system, this before perform the update (so replace the existing wv files) and break all add-ons. So if the command return error avoid the update and inform the user on what to do
• A better message for this case of problem, with reference to what to do (like read GitHub Wiki FAQ)

I hope something will be done about it because it's so annoying for both the add-ons maintainers and the users who don't know what to do

[dagwieers]

Well, we do not expect this to happen again. In both cases this was a human error. They have been fixed after the first incident.

What is unfortunate is that we had this fixed, but did not release it because there was no dire need to do so. We already released an emergency fix for the previous case which was urgent. And this fix was scheduled for the next release, but there was no new reason for releasing a new version.

Or as I put it on Slack:

:point_right: Lessons learned: If you have a fix which is not impacting your users now, but may in the future, do not delay out of convenience (or lack of dire need).

[dagwieers]

i know that the wv library search cannot always be perfect

The WV library search is perfect, if we provide it with a good list. The problem is that the original list we started from was compiled by ourselves by looking up the architecture based on specific models. And that was a hard, painful and erroneous task. Since that day pre-compiled lists exist with exact architectures which avoid this issue from happening again.

This is documented in the code and in the Wiki. https://github.com/emilsvennesson/script.module.inputstreamhelper/blob/e77df9161f0ebb32a635034534b123ccdfd45904/lib/inputstreamhelper/config.py#L82-L85

[CastagnaIT]

is very good that the list has been fixed, but is better also add a proper feedback to the user in case for any reason this might happen (although it should no longer happen) it makes sense to do a check before break a working system

[CastagnaIT]

I think it is reasonable, if it seems superfluous to you, you are free to close this issue

[dagwieers]

@CastagnaIT IMO the best way forward is #69 and peak3d/inputstream.adaptive#497, there are various situations where a working system is updated for no reason, and risks breaking that working system. If Kodi would provide us with specific error information on playback, this could trigger a Widevine update, rather than us doing it proactively for no good reason.

I think it is reasonable, if it seems superfluous to you, you are free to close this issue

I like to listen to what the other maintainers think about this, what I stated is my personal opinion, not the project's opinion :wink:

We hope that at some point in the near future Google will have a more sensible way of distributing ARM (and ARM64) images as part of the LaCrOS project. This has not materialized yet (or we haven't detected it yet). See #414

As always, all feedback is good feedback. It allows us to rethink what we are doing and how we are doing things.

[CastagnaIT]

there are various situations where a working systems is updated for no reason, and risks breaking a working system

yes it is right, i think there are more side that could be used to check this type of problems and not easy to do concise summaries

• Checks post-download
• Checks in case of playback failed (as you say)

We hope that at some point in the near future Google will have a more sensible way of distributing ARM (and ARM64) images

i hope really, being forced to use these workarounds is annoying

[CastagnaIT]

I have found a solution, this is an working example, you can test yourself without Kodi and is Python2/3 compatible

lib_check.zip

Basically with this you can load the widevine library directly at low level in python, if the architecture of the file not match to the architecture of the operative system will fail if the file is corrupted will fail

in this way you have a good way to check the widevine file on the post-download, then check if the downloaded wv file from the update match the system architecture and it is working

i have added the possibility to read the widevine version directly by quering the file so/dll then you can determine the also the file version without supplemental files

These are my tests:

• Under x86_64 Linux distribution with ARM architecture Widevine .so >> fail to load (wrong architecture)
• Under x86_64 Linux distribution with x86_64 architecture Widevine .so >> load with success and return the lib version
• Under Windows with Python 32bit and 64bit Widevine .dll >> fail to load (wrong architecture)
• Under Windows with Python 32bit and 32bit Widevine .dll >> load with success and return the lib version

[dm2912]

with upgrading its not so much of an issue, you can downgrade

My widevine updated, broke castagnal's add-on, so i downgraded back to previous widevine awaiting a fix

The only time its a real issue is, if - in that narrow window between new CDM and fixing any bugs caused by it - a user does a fresh install that installs widevine, as then they have no route to downgrade to prior versions.

But thank you both for looking into this for the future.

[CastagnaIT]

it is exact you can not downgrade widevine lib if you have installed from scratch 😊 this is not only a check system but you can adopt it to elaborate some type of fallback system

[dagwieers]

with upgrading its not so much of an issue, you can downgrade

My widevine updated, broke castagnal's add-on, so i downgraded back to previous widevine awaiting a fix

Correct, this we added after the first incident we had as well, which was related to a newer Widevine CDM which had regressions caused poorer playback. We decided then that the user should be able to go back and test with previous releases.

it is exact you can not downgrade widevine lib if you have installed from scratch blush this is not only a check system but you can adopt it to elaborate some type of fallback system

I also wanted us to add the option to select any available online version to roll back to, but that would not work for ARM anyway as we work with the ChromeOS version and don't know what Widevine version is part of what ChromeOS image. (In fact we assume a newer image has a newer Widevine, but that may not always be the case.