Widevine DRM content not playing after december update

Help and Support Raspberry Pi
1

Hi,
after installing the december update, I could no longer play content which is protected by Widevine DRM on my Raspberry Pi 3.

Log:

22:21:41.247 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: Platform information: 
('Linux', 'raspberrypi', '4.9.29-13-osmc', '#1 SMP PREEMPT Thu Dec 21 17:18:07 UTC 2017', 'arm', '')
22:21:41.248 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: jsonrpc payload: {'params': {'addonid': 'inputstream.adaptive'}, 'jsonrpc': '2.0', 'id': 1, 'method': 'Addons.GetAddonDetails'}
22:21:41.248 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: jsonrpc response: {"id":1,"jsonrpc":"2.0","result":{"addon":{"addonid":"inputstream.adaptive","type":"kodi.inputstream"}}}
22:21:41.249 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: jsonrpc payload: {'params': {'properties': ['enabled'], 'addonid': 'inputstream.adaptive'}, 'jsonrpc': '2.0', 'id': 1, 'method': 'Addons.GetAddonDetails'}
22:21:41.250 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: jsonrpc response: {"id":1,"jsonrpc":"2.0","result":{"addon":{"addonid":"inputstream.adaptive","enabled":true,"type":"kodi.inputstream"}}}
22:21:41.250 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: inputstream.adaptive is installed and enabled.
22:21:41.274 T:1386214144   DEBUG: [script.module.inputstreamhelper-0.2.4]: Unsupported Widevine architecture found: arm

The reason is that the InputstreamHelper for some reason reads the system architecture as ‘arm’ instead of ‘armv7l’ (line 1 of the log). This is weird as I get the correct architecture when I run the platform.uname() command by hand.

>>> platform.uname()
('Linux', 'raspberrypi', '4.9.29-13-osmc', '#1 SMP PREEMPT Thu Dec 21 17:18:07 UTC 2017', 'armv7l', '')

As a workaround, I used this patch on ~/.kodi/addons/script.module.inputstreamhelper/lib/inputstreamhelper.py:

--- inputstreamhelper.py        2018-01-11 20:52:18.396650622 +0100
+++ inputstreamhelper_new.py    2018-01-11 20:53:32.546325929 +0100
@@ -128,8 +128,9 @@
         if arch in config.X86_MAP:
             return config.X86_MAP[arch]
         elif 'armv' in arch:
-            arm_arch = 'armv' + arch.split('v')[1][:-1]
-            return arm_arch
+            return arch[:5]
+        elif arch == 'arm':
+            return 'armv7'
 
         return arch
2

Sounds similar to [TESTING] OSMC images for Debian Stretch - #50 by martinrevert.

But the poster there suggested setting arch to arm7 not armv7.

Can you please confirm if that also works?
For now I think we just want to split the helper routines to be Vero 4K only

Can you also let me know what add-on you’re using that needs InputStream (provided it doesn’t violate our forum rules) and which version of Kodi you’re using?

Sam

3

Hmmm careful everybody…i’m using the native provided inputstream.adaptive and Netflix is working OK on rbp3 with Kodi 18.

Seems obviously related to this arch missidentification that I pointed yesterday, but this case is easy to solve removing that script.module.inputstreamhelper and using the InputStream plugin provided by OSMC on KODI, which is clearly not impacted by the binary identification. The only problem I see is that maybe the op could be using that 3rd party InputStream module to make Netflix work over KODI 17, because the InputStream provided by OSMC over Kodi 17 don’t work. Fair, i suppose, but i’m just guessing, let’s see what op adds to this.

Solutions so far?

  • Patching the 3rd party inputStream library like the op did is dirty but valid and it will not be modified by OSMC updates, a least until a stable OSMC with Leia arrives.
  • Migrating prematurely to OSMC Kodi 18 is safe and stable for Netflix purposes and general use, but no so stable and working retrogaming, and specially not for addons with multiple arch binaries selection, because Stretch is required.
  • The best solution will be not in the op hands and, as I suggested yesterday, will be mimic in Stretch the architecture platform and uname returns that were working over the old linuxes for all OSMC covered platforms (Vero, rbp1, rbp2/3). If for some reason this is not possible, is reasonable to argue that OSMC is hitting a big compatibility problem.

PS, for general interest my actual working Netflix config is this;

  • rbp3, normal clocking (allows 480p res, overclocking allows 720p res)
  • Netflix plugin https://github.com/asciidisco/plugin.video.netflix .
  • Latest KODI 18 by @gmc
  • Latest stable main Debian Stretch
  • inpustream.adaptive → The native preinstalled over OSMC KODI 18.
  • Widevine binary: arm version, widely available on the interwebs.
4

Going to do this for now until we have a real use for it to be on other platforms. It has however shown us potential problems which is good.

There’s a reason why the patch was originally added.
Python considers platform to be aarch64 because the kernel is 64-bit but we have armv7 userland and armv7 libwidevine.

This resolved Netflix on Vero 4K.

The helper routines will also be used to trap some other calls however that will benefit all platforms.

Should it be ‘arm7’ or ‘armv7’. Seems to me the options should be ‘armv6l’ or ‘armv7’ accordingly, with Vero 4K returning ‘armv7’ to reflect its true userland.

5

Yep, totally understandable. What a pity that Eben didn’t push the idea of an aarch64 kernel and software for rbp2/3. All this could be more easy for everybody, otherwise i don’t see how to reach all addon devs to standardize another id, but it definitively needs to be “linux ARM 64”. No hardcoded addons could be easy to redirect to “Android ARM 64” binaries, but is not wife-safe, and definitively is a problem with harcoded binary selection addons.

Not easy, at least not easy until more proper linux 64bit ARM devices get Kodi.

6

This has been discussed quite a bit on the Pi GitHub and forums. RBP3 supports 64-bit worlds but it’s not desirable to create two separate worlds. Interfacing to the GPU is not trivial either. I do believe you can boot aarch64 mode, but it is quite limiting.

The Vero 4K is quite different. As it’s based on Debian upstream, everything was supposedly all there. But I found a few problems in userland (Cortex A53 quirks that had been discovered after Debian Jessie was built) in very early 2017.

We would have also lost binary compatibility (i.e. no Netflix too). Some plugins also don’t built Aarch64 binaries.

We coul do a complete 64-bit kernel, 64-bit userland now. Even the APT userland infra is there as the kernel is considered an aarch64 package. But there is no benefit of this. Benchmarks aren’t really showing any improvements for our use case.

Sam

7

But there is no benefit of this. Benchmarks aren’t really showing any improvements for our use case.

Wow, I expected at least some marginal performance gain with a complete 64 bit config…but nothing? :flushed:

8

I’m using the Sky Go (Germany) addon on Kodi 17.6.

I can’t test it right now but from what I have seen in the source code of InputstreamHelper, the architecture must be in this list (~/.kodi/addons/script.module.inputstreamhelper/lib/config.py:28):

WIDEVINE_SUPPORTED_ARCHS = [
    'x86_64',
    'x86',
    'armv7',
    'armv8',
    'aarch64',
    'aarch64_be'
]

(If the architecture starts with ‘armv’, the last character is ignored, so e.g. armv7l would be fine).

If I’m not mistaken, the InputstreamHelper addon was introduced in Kodi 17.6 to automatically install Widevine libraries when needed instead of letting the user install them by hand.
(At the moment, users still have to change a library by hand due to this issue: libwidevinecdm now depends on nss/nspr · Issue #8 · emilsvennesson/script.module.inputstreamhelper · GitHub)

I’m not sure if the addon was installed by default or as a dependency of the Sky Go addon.

Ways I see to solve this issue:

  1. Correctly report the architecture as ‘armv7l’.

  2. Remove the InputstreamHelper addon as suggested by @martinrevert.

  3. Keep reporting the architecture as ‘arm’ and add it to the config.py of the InputstreamHelper. This is equivalent to my workaround in post #1. You mustn’t do that on a Raspberry Pi 1 though, as Widevine doesn’t work there.

9

You might see a little bit of an improvement for specific workloads, but it’s very minor, and probably not beneficial for us at all.

10

This is the best way then.

Sam

11

would this patch work with vero 4k, too? (and how exactly is this patch “applied”? - i have tried to edit the file manually but it didn’t work…)

i’m using sky go and have a widevine drm problem…

12

This has already been resolved for Vero 4K I believe

13

hmm not for me :frowning:
i’ll try to reproduce the error tonight and will post my log!
maybe it’s a totally different problem…
i’m just a user :wink:

cheers

14

Yes, it is.
Netflix, Amazon and SkyGo are running after editing inputstreamhelper.py as described above. Erase the content of cdm folder, install Amazon-Add-on and the dialogue to download the libraries appears.

Running on Kodi 18 newest build on a Vero 4K

15

hmm, which “cdm” folder? and how is the patch “applied”?

anyway. this is my error on kodi.log: 19:25:21.558 T:3387945728 DEBUG: [script.module.inputstreamhelper-0.2.4]: Plat - Pastebin.com

16

I edited it with WinSCP. Delet the lines with a “-”; add the lines with a “+”.

17

Okay, seems this worked, but now i get another message:
“Widevine CDM is required…”
if i try to install it tells me that i need to download a chrome os recovery with 2 gigs?

btw: where to i get the Amazon-Add-On from? and where did you the SkyGo addon from?

18

That’s correct! But not with raspi at the moment, only vero 4k.

19

what is correct? should i really download the hole recovery img?

20

Nope, because for Rpb2/3 there’s no solution for it at the moment, if u’ve got a vero u can download it.