Latest Widevine 4.10.2252.0 fails to load

[wagnerch]

It appears Google may have changed the latest Widevine libraries, the size has changed by about 1M, and it is not linking all of the same libraries as it used to (perhaps some stuff is statically linked now). In any case these are the errors, but there isn't enough logging to know the issue. Also the dlerror() message is squashed and never bubbles up.

2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: Unable to load widevine shared library (/storage/.kodi/cdm/libwidevinecdm.so)
2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: OpenDRMSystem failed

Related issues:
CastagnaIT/plugin.video.netflix#1154

Working CDM:

13505.111.0/libwidevinecdm.so:
linux-vdso.so.1 (0xbefbd000)
/usr/lib/libarmmem-v7l.so (0xb6808000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb67df000)
libm.so.6 => /usr/lib/libm.so.6 (0xb6776000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb6763000)
librt.so.1 => /usr/lib/librt.so.1 (0xb674c000)
libnss3.so => /usr/lib/libnss3.so (0xb664f000)
libnssutil3.so => /usr/lib/libnssutil3.so (0xb661c000)
libnspr4.so => /usr/lib/libnspr4.so (0xb65e5000)
libc.so.6 => /usr/lib/libc.so.6 (0xb64a6000)
/usr/lib/ld-linux-armhf.so.3 (0xb6f66000)
libplc4.so => /usr/lib/libplc4.so (0xb6f8f000)
libplds4.so => /usr/lib/libplds4.so (0xb6f8b000)

Non-working CDM:

13816.64.0/libwidevinecdm.so:
linux-vdso.so.1 (0xbedb9000)
/usr/lib/libarmmem-v7l.so (0xb5dd7000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb5dc4000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb5d9b000)
librt.so.1 => /usr/lib/librt.so.1 (0xb5d84000)
libm.so.6 => /usr/lib/libm.so.6 (0xb5d1b000)
libc.so.6 => /usr/lib/libc.so.6 (0xb5bdc000)
/usr/lib/ld-linux-armhf.so.3 (0xb6f78000)

[wagnerch]

ARM, LibreELEC

[dagwieers]

This affects all ARM-based Linux systems (not Android systems). And what is worse, it appears Google will be revoking older Widevine CDM versions as of 2021-05-31, so we have 3 weeks to get a fix out, or all Widevine-encoded content will stop working. https://www.widevine.com/news

[wagnerch]

This appears to be the dlerror:
cannot allocate memory in static TLS block

At least with testing a simple C program to just do a dlopen:

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv)
{
    void *dl = dlopen("libwidevinecdm.so", RTLD_LAZY);
    if (!dl) {
        char *msg = dlerror();
        fprintf(stderr, "ERROR: %s\n", msg);
    }
}

[matthuisman]

Do we have access to 4.10.2252.0 for other platforms?
I know 4.10.2209.0 works fine on Windows and Linux x86_64 for example.

See Linux and Chrome OS list different versions...
So maybe 4.10.2252.0 is just for Chrome OS and is now more closely linked - that is where IA helper extracts it from after all.

https://dl.google.com/widevine-cdm/versions.txt also lists 4.10.2209.0/1 as latest

If thats the case, it would mean we need to find a new source for a Linux ARM build of Widevine blob.
Raspberry Pi has a version, so be interested to see if that gets updated...
Did anyone manage to get more info from them where they were getting it from?

[wagnerch]

I think libwidevinecdm0 comes from Ventz. It's not fully clear whether it is an official Google agreement. My guess is they may be pulling it from the same sources.

https://blog.vpetkov.net/2020/03/30/raspberry-pi-netflix-one-line-easy-install-along-with-hulu-amazon-prime-disney-plus-hbo-spotify-pandora-and-many-others/

[matthuisman]

i dont think they would take it from there to be honest. They are quite big org and seem to do things "by the book".
Ventz was probably pulling it from Chrome OS as well - that seems to be the only actual source.

Just tried using my Widevine pull script, and still no Linux ARM builds - only Darwin ARM64 and the others.

I wonder if those Chrome blobs are using newer version of one of the linked libs or something like that?

[wagnerch]

I know it's not a special build for Raspberry Pi, it has the same sha1 as the one pulled from ChromeOS. But that may not really indicate much of anything.

[matthuisman]

just had a thought over herE:
#679 (comment)

We are sure the blobs aren't AARCH64 now?
Is the HW they pulling from 32 or 64 bit?
Maybe latest Chrome OS has switched fully to 64 bit.
We did just get a ARM64 build for Darwin / MAC... so wouldn't be huge surprise Chrome OS followed

[wagnerch]

They are not, it's still armhf. You can tell because it has a dependency on the armhf dynamic linker:
/usr/lib/ld-linux-armhf.so.3 (0xb6fb3000)

If you compile with:
arm-linux-gnueabihf-gcc-8 -Wall -o wvdl wvdl.c -ldl -Wl,--no-as-needed ~/libtcmalloc.so.4.5.3

The last 2 arguments are forcing a link to libtcmalloc.so.4 even though it is not needed by the C program, and run with LD_DEBUG=all you see it gets past linking and calls init in libwidevinecdm and results in a segmentation fault. My guess is Chromium is linking libtcmalloc.so.4, so the symbols are already loaded and TLS is already allocated, and malloc() has been replaced at this point before they dlopen(libwidevinecdm.so). Don't know though. I noticed there are 4 new global symbols:
0080efc0 g D google_malloc 00000000 Base .protected __start_google_malloc
0080e688 g D malloc_hook 00000000 Base .protected __start_malloc_hook
00812c70 g D google_malloc 00000000 Base .protected __stop_google_malloc
0080efbc g D malloc_hook 00000000 Base .protected __stop_malloc_hook

These are related gperftools (which includes tcmalloc). Not really an expert on all of this dynamic linker & ELF binary stuff. But could't really go much further than that.

LD_DEBUG=all LD_LIBRARY_PATH=/storage:/storage/.kodi/userdata/addon_data/script.module.inputstreamhelper/backup/13816.64.0/ ./wvdl

      3705:     calling init: /usr/lib/librt.so.1
      3705:
      3705:
      3705:     calling init: /storage/.kodi/userdata/addon_data/script.module.inputstreamhelper/backup/13816.64.0/libwidevinecdm.so
      3705:
Segmentation fault

[matthuisman]

thanks for confirming :)

[wagnerch]

BTW, this is what 1679 looks like through the same program (through the point where the segfault happens):

      3715:
      3715:     calling init: /usr/lib/librt.so.1
      3715:
      3715:
      3715:     calling init: /storage/.kodi/userdata/addon_data/script.module.i
nputstreamhelper/backup/13505.111.0/libwidevinecdm.so
      3715:
      3715:     opening file=/storage/.kodi/userdata/addon_data/script.module.in
putstreamhelper/backup/13505.111.0/libwidevinecdm.so [0]; direct_opencount=1
      3715:
      3715:
      3715:     calling fini: /storage/.kodi/userdata/addon_data/script.module.i
nputstreamhelper/backup/13505.111.0/libwidevinecdm.so [0]
      3715:
      3715:
      3715:     calling fini: /usr/lib/libnss3.so [0]

[matthuisman]

anyone got a copy of the new blob that they can upload and send me?
Nevermind - i've just downloaded the chrome os :)

[matthuisman]

so, opening that new blob in text editor, there is all the below text in it near the top that older versions dont have
are we sure this blob is good??
has anyone got a chrome book to try?
Has google messed up?

Error text from top of blob (just opening with notepad):
https://pastebin.com/raw/KDHfY8QL

[wagnerch]

Did you get this sha1?

4d129768d3753328a837a940e6ee903830c791c4 libwidevinecdm.so

I downloaded 2 separate ChromeOS images and got the same sha1, and it does dynamically link if the binary doing the dlopen is linked with tcmalloc, just crashes.

No Chromebook here.

[matthuisman]

did you see all the error text... pretty sure that shouldnt be inside the blob...
https://pastebin.com/raw/KDHfY8QL

I think it's a bad blob...
maybe Google is pushing updates via Chrome once it's booted?
Or they have messed up?

We need to confirm with a chrome OS user if it works...
If yes - get them to pull the blob and we can compare it...
if its different then chrome are pushing an update to it

[wagnerch]

Yeah, possibly. Or it could be what you said earlier, "maybe 4.10.2252.0 is just for Chrome OS and is now more closely linked".

bits of that blob are from:
https://github.com/webrtc-uwp/chromium-base/blob/master/trace_event/memory_infra_background_whitelist.cc

[wagnerch]

Well, this is interesting, 2252 has a .init section (which is where I am crashing), 1679 does not. In that .init section it calls InitializeCdmModule_4, which is problematic because CdmAdapter normally does that.

Disassembly of section .init:

0080e674 <_init@@Base>:
  80e674:       e92d4008        push    {r3, lr}
  80e678:       ebefbc00        bl      3fd680 <InitializeCdmModule_4@@Base-0xe0>
  80e67c:       e8bd8008        pop     {r3, pc}

Disassembly of section .fini:

0080e680 <_fini@@Base>:
  80e680:       e92d4008        push    {r3, lr}
  80e684:       e8bd8008        pop     {r3, pc}

[mediaminister]

2252 has a .init section (which is where I am crashing), 1679 does not.

This doesn't make sense to me:

BTW, this is what 1679 looks like through the same program (through the point where the segfault happens):

  3715:
  3715:     calling init: /usr/lib/librt.so.1

[matthuisman]

below posted by Fuzzard on Slack

"
i think your libwidevine.so issue is going to be because we dont use (and therefore link) some new/changed libs
namely boringssl and tcmalloc

    81: 00000000009d4600     0 NOTYPE  GLOBAL PROTECTED   17 __start_google_malloc
    82: 00000000009d3e70     0 NOTYPE  GLOBAL PROTECTED   16 __start_malloc_hook
    83: 00000000009d8730     0 NOTYPE  GLOBAL PROTECTED   17 __stop_google_malloc
    84: 00000000009d45d3     0 NOTYPE  GLOBAL PROTECTED   16 __stop_malloc_hook

   152: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND OPENSSL_memory_alloc
   153: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND OPENSSL_memory_free
   154: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND OPENSSL_memory_get_size
   155: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND sdallocx"

"

below is me again:

The error we get when trying to load the lib is "cannot allocate memory in static TLS block"
after a google, seems similar fix for other issues is export LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libX.so
before executing. so it does seem that error is related to not having the libraries linked.
I assume both boringssl and tcmalloc are available and loaded in Chrome OS

@CastagnaIT on slack suggested trying the widevine blob with chromium browser on RPI and see if that works.
seems like a good idea and be interested in the results. I can try that tomorrow of no-one beats me to do.

[wagnerch]

Here is the chrome dependencies from the 138614 image:

$ readelf -d chrome

Dynamic section at offset 0x87e2ee8 contains 55 entries:
  Tag        Type                         Name/Value
 0x0000000f (RPATH)                      Library rpath: [$ORIGIN]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libsmime3.so]
 0x00000001 (NEEDED)                     Shared library: [libnss3.so]
 0x00000001 (NEEDED)                     Shared library: [libnssutil3.so]
 0x00000001 (NEEDED)                     Shared library: [libnspr4.so]
 0x00000001 (NEEDED)                     Shared library: [libcups.so.2]
 0x00000001 (NEEDED)                     Shared library: [libdbus-1.so.3]
 0x00000001 (NEEDED)                     Shared library: [libfontconfig.so.1]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libexpat.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdrm.so.2]
 0x00000001 (NEEDED)                     Shared library: [libsync.so]
 0x00000001 (NEEDED)                     Shared library: [libxkbcommon.so.0]
 0x00000001 (NEEDED)                     Shared library: [libgbm.so.1]
 0x00000001 (NEEDED)                     Shared library: [libevdev.so]
 0x00000001 (NEEDED)                     Shared library: [libgestures.so.0]
 0x00000001 (NEEDED)                     Shared library: [libasound.so.2]
 0x00000001 (NEEDED)                     Shared library: [libcras.so.0]
 0x00000001 (NEEDED)                     Shared library: [libassistant.so]
 0x00000001 (NEEDED)                     Shared library: [libffi.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc++.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc++abi.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld-linux-armhf.so.3]

Wondering if boringssl & tcmalloc is statically linked in chrome?

[dagwieers]

I can confirm that the PHASER version 13816.64.0 image (also reported as 90.13816.0 or ChromeOS 90.0.4430.100) works fine on a Chromebook using Widevine on Netflix.

[dagwieers]

@matthuisman If I understand the error correctly, it means some loaded library is deplating the preallocated TLS area. So that must be one of the libraries loaded prior to the error.

There could be a few reasons for this:

• The preallocated TLS area is now smaller than before (not likely)
• Other stuff is using the TLS area that wasn't using it before
  • Could be an external library that is now loaded and wasn't before (not likely)
  • Could be the Widevine CDM itself that is using more
  • Could be that due to threading, a larger number of threads are using the same size, thus more

The solution could be to:

• Increase the preallocated size of the TLS area (is that possible?)
• Reduce the existing use of the TLS area (this is what is done in similar cases on Google)

And a workaround that was mentioned is to preload the library complaining so it has sufficient TLS area when loaded.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1722181#c20

[dagwieers]

On my x64 laptop, I can see libwidevinecdm.so itself is using a much larger TLS area now (96 bytes instead of 24 bytes).

[dag@moria ~]$ readelf -Wl libwidevinecdm.so.x64.old.working | grep TLS
  TLS            0x321020 0x0000000000322020 0x0000000000322020 0x000010 0x000018 R   0x8
[dag@moria ~]$ readelf -Wl libwidevinecdm.so.x64.new.working | grep TLS
  TLS            0x9d8080 0x00000000009da080 0x00000000009da080 0x000014 0x000060 R   0x40

[wagnerch]

@dagwieers Since you have a Chromebook that runs with this image, perhaps you can run Chrome with LD_DEBUG?

Something like this on the command line:
LD_DEBUG=bindings LD_DEBUG_OUTPUT=/tmp/ld /opt/google/chrome/chrome

Should output a /tmp/ld.pid file reporting dynamic linkers bindings (searching for symbols and where they are found). That could at least validate whether libwidevinecdm is looking for the 8 symbols noted earlier.

Example:
381634: binding file ls [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `getenv' [GLIBC_2.2.5]

basically this is running LD_DEBUG on the "ls" command, and you can see ls is resolving getenv@GLIBC_2.2.5 from libc.so.6.

[dagwieers]

@wagnerch No, I cannot. I don't have a console on these. And since they are being used, I cannot just go and scratch them :-/

Update: ChromeOS v91 can now give console access without the need to reinstall the laptop 👍🏻

[wagnerch]

@matthuisman @CastagnaIT If you haven't gotten to it, using this libwidevinecdm on Raspberry Pi OS results in the following errors on the terminal when running chromium-browser and accessing Netflix:

[1423:1:0511/123011.891141:ERROR:cdm_module.cc(139)] CDM at /opt/WidevineCdm/_platform_specific/linux_arm/libwidevinecdm.so could not be loaded.
[1423:1:0511/123011.892512:ERROR:cdm_module.cc(140)] Error: /opt/WidevineCdm/_platform_specific/linux_arm/libwidevinecdm.so: cannot open shared object file: Operation not permitted

[wagnerch]

I posted this on emilsvennesson/script.module.inputstreamhelper#437 (comment)

There are some other things bothering me:

$ readelf -d libwidevinecdm-4.10.2252.0.so
Dynamic section at offset 0x816c58 contains 34 entries:
  Tag        Type                         Name/Value
...
...
 0x00000024 (<unknown>: 24)              0x1cf4
 0x00000023 (<unknown>: 23)              0x2b8
 0x00000025 (<unknown>: 25)              0x4

What are these unknown attributes in the dynamic section? Based on some research this is an Android-specific ELF extension called relative relocations (RELR), see:
https://groups.google.com/g/generic-abi/c/bX460iggiKg
https://chromium.googlesource.com/chromium/src.git/+/master/third_party/android_crazy_linker/src/src/crazy_linker_relr_relocations.h#12
https://android.googlesource.com/platform/bionic/+/master/libc/include/elf.h#246

There is also a ".relr.dyn" section in the library. Binutils has no idea what it is, one of the tools actually complains about it (I think objcopy, when I tried to strip the .init and .fini sections).

Also, when runninng:
LD_PRELOAD=libwidevinecdm.so /bin/ls

And analyzing the core dump:

(gdb) bt
#0  0x003fd6a4 in ?? ()
#1  0xb6f50a48 in call_init (l=<optimized out>, argc=argc@entry=1,
    argv=argv@entry=0xbef3fa14, env=env@entry=0xbef3fa1c) at dl-init.c:74
#2  0xb6f50b20 in call_init (env=<optimized out>, argv=<optimized out>,
    argc=<optimized out>, l=<optimized out>) at dl-init.c:37
#3  _dl_init (main_map=0xb6f739a0, argc=1, argv=0xbef3fa14, env=0xbef3fa1c)
    at dl-init.c:121
#4  0xb6f409a4 in _dl_start_user () from /lib/ld-linux-armhf.so.3

0x3fd6a4 is the virtual address for InitializeCdmModule_4, which is called by the ".init" section.

$ arm-linux-gnueabihf-nm -D libwidevinecdm-4.10.2252.0.so |grep InitializeCdmModule_4
arm-linux-gnueabihf-nm: libwidevinecdm-4.10.2252.0.so: unknown type [0x13] section `.relr.dyn'
003fd760 T InitializeCdmModule_4

Oh, and hey there is nm complaining about an unknown section ".relr.dyn". Interestingly, gdb sees this symbol at:
(gdb) print InitializeCdmModule_4
$1 = {<text variable, no debug info>} 0xb61b1760 <InitializeCdmModule_4>

So to me that suggests maybe the relocation was not done, because glibc doesn't understand it? Not sure.

[jamieburchell]

@jamieburchell I pushed an updated version of libc6 to OSMC's APT repository in early September. No manual intervention should be necessary at all. Just make sure you're on a recent version of OSMC.

Cheers

Sam

There's a slight problem with that as I need to stay with Kodi 18 on my Pi 2 (or rather, I would prefer to). It must have pulled the libc6 from your repo when I did sudo apt-get install --only-upgrade libc6 since I didn't install the repo from wagnerch-buster-ppa.list. Anyway, I have a working Widevine using the .so from https://k.slyguy.xyz/.decryptmodules/widevine/4.10.2252.0-linux-armv7.so

[horstle]

@jamieburchell
If it works with that libwidevinecdm.so, it should work with all.

[jamieburchell]

@jamieburchell
If it works with that libwidevinecdm.so, it should work with all.

Oh yes, you're absolutely right. Turns out the only thing I had to do in OSMC / Kodi 18 was to update the libc6 library from the OSMC repo.

[ostanislaw]

I have OSMC latest stable. Should I update(downgrade) if I have following library which still works with latest widevine:
libc6_2.28-110.1_armhf.deb
Someone shared a solution about 2 months ago and it is fine so far.

Now I tried installing the version from wagnerch ppa and it says it would remove a lot of packages, probably there are some incompatibilities:

osmc@osmc ~> sudo apt-get install libc6=2.28-10
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  autotools-dev dh-python icu-devtools libboost-date-time1.67.0 libboost-serialization1.67.0 libc-dev-bin libgmp-dev libgmpxx4ldbl libgnutls-dane0 libgnutls-openssl27 libgnutlsxx28 libidn2-dev libp11-kit-dev libtasn1-6-dev libunbound8 libvncclient1
  libvncserver-config libvncserver1 linux-libc-dev nettle-dev
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  icu-devtools libicu63
Suggested packages:
  glibc-doc
The following packages will be REMOVED:
  build-essential g++ g++-8 libboost-date-time-dev libboost-date-time1.67-dev libboost-dev libboost-filesystem-dev libboost-filesystem1.67-dev libboost-serialization1.67-dev libboost-system-dev libboost-system1.67-dev libboost1.67-dev libc6-dev
  libexpat1-dev libfreetype6-dev libgnutls28-dev libicu-dev libjpeg-dev libjpeg62-turbo-dev libpng-dev libpython-dev libpython2-dev libpython2.7-dev libpython3-dev libpython3.7-dev libstdc++-6-dev libstdc++-8-dev libtool libvncserver-dev libxml2-dev
  libxslt1-dev python-dev python2-dev python2.7-dev python3-dev python3.7-dev zlib1g-dev
The following packages will be upgraded:
  icu-devtools libicu63
The following packages will be DOWNGRADED:
  libc6
2 upgraded, 0 newly installed, 1 downgraded, 37 to remove and 11 not upgraded.
Need to get 10,6 MB of archives.
After this operation, 368 MB disk space will be freed.
Do you want to continue? [Y/n] 

[wagnerch]

I have OSMC latest stable. Should I update(downgrade) if I have following library which still works with latest widevine: libc6_2.28-110.1_armhf.deb Someone shared a solution about 2 months ago and it is fine so far.

Now I tried installing the version from wagnerch ppa and it says it would remove a lot of packages, probably there are some incompatibilities:

OSMC (and Raspberry Pi OS Buster/Bullseye, XBian Bullseye), as I understand it from comments above, should include these patched libc6 binaries now. So you do not need that PPA, if you have it installed then you can remove the PPA via (if you used the PPA install instructions):
sudo rm -f /etc/apt/sources.list.d/wagnerch-buster-ppa.list

Then proceed with a normal apt-get update, apt-get upgrade. I believe Sam also pushed a fix for OSMC Buster. By the way "libc6=2.28-10" is the unpatched version, if you want to install that then you would need to install version-locked dependencies as well (based on your output it looks like libc6, libc6-dev, libc-dev-bin). The patched version in that PPA is libc6=2.28-110.1, I believe OSMC is also using the same version as my PPA.

[ostanislaw]

@wagnerch Thanks, removed your ppa back. I got confused with the new PPA. I thought it must be different version that the one I've installed long time ago. My current version (110-1) is from osmc ppa. No issues with this package BTW.

> apt-cache policy libc6
libc6:
  Installed: 2.28-110.1
  Candidate: 2.28-110.1
  Version table:
 *** 2.28-110.1 500
        500 http://apt.osmc.tv buster/main armhf Packages
        100 /var/lib/dpkg/status
     2.28-10 500
        500 http://ftp.debian.org/debian buster/main armhf Packages

[DjDiabolik]

@wagnerch do you have a raspberry kodi setup on your home ?
Can you check if DAZN addons it's works (or problably some other addons using widevine) or also you obtain a completely struttering and buffering reproduction issue ?

[pejobo]

@DjDiabolik I don't know the background of your question but I can confirm that it's working just fine

[horstle]

There are some reports about stuttering with the latest libwidevinecdm.so version 4.10.2391.0. Apparently it doesn't happen with all addons, Not yet sure what's going on, but going back to 4.10.2252.5 apparently helps.

[stsichler]

I can also confirm massive stuttering with latest widevine on up-to-date XBian on Raspberry Pi 3, I also had to downgrade winevine for this reason.

[BlackEdder]

I can also confirm massive stuttering with latest widevine on up-to-date XBian on Raspberry Pi 3, I also had to downgrade winevine for this reason.

I have a related problem with the newest version in that suddenly it keeps buffering, where before it was fine. Could it be that the latest widevine version does not properly adhere to maximum resolution settings?

EDIT: downgrading libwidevinecdm.so solves this issue.

[glennguy]

Does anyone have any rough stats on CPU usage before/after downgrading versions?

[DjDiabolik]

@DjDiabolik I don't know the background of your question but I can confirm that it's working just fine

Lol sorry me it was my intention to try to contact @wagnerch because is as found a valid solution when this issue it's appears on all arm devices.
I thought maybe he might know something about it.....

[wagnerch]

@DjDiabolik I personally haven't used the new Widevine, I typically turn off InputStream Helper's automatic updates and run it until it doesn't work.

@glennguy would know more of the guts here. But I believe WidevideCDM doesn't actually decode the frames, I think it just decrypts them? So it could be CPU cycles on the decryption side, which I think he was looking for some info on CPU utilization. Since this is also using SW decoding, and depending on hardware, 1080p is pretty "hard". My RPi4 has no problem handling 1080p from Netflix, but my Vero 4k+ (Amlogic S905D / GXL) not so much -- best it can handle is 720p otherwise it stutters & consumes all 4 cores.

[glennguy]

Yes that was what I was getting at.
The CDM can decode the frames too - secure decoding can be required depending on what the provider requires, NF is setup this way I believe.
I built this yesterday with a small change to force inputstream.adaptive to open separate CDM sessions for audio and video. Ends up making 2 license requests to the license server but not really a big deal atm, more interested in seeing if this fixes the issue or not:
inputstream.adaptive-19.0.2.1.zip

The same change was made in the Android decrypter a while back which seemed to fix a very similar problem.

[rocktobe]

Yes that was what I was getting at. The CDM can decode the frames too - secure decoding can be required depending on what the provider requires, NF is setup this way I believe. I built this yesterday with a small change to force inputstream.adaptive to open separate CDM sessions for audio and video. Ends up making 2 license requests to the license server but not really a big deal atm, more interested in seeing if this fixes the issue or not: inputstream.adaptive-19.0.2.1.zip

The same change was made in the Android decrypter a while back which seemed to fix a very similar problem.

Hello,
I have stuttering/buffering problem with amazon VOD addon.
I can only use audio or video sessions without trouble but when I have both together it's stuttering or buffering.
I got the problem with the latest widevine version 4.10.2391.0. and I'm unable to downgrade to 4.10.2252.0.
Older Widevine version won't work at all.
I use Libreelec 9.2.8 and Leia 18.9.
Can I just install inputstream.adaptive-19.0.2.1.zip via install addon repository (¨*.zip)?
Can I disable my actual inputstream addon or do I need to uninstall it first?

Thanks

[glennguy]

Can I just install inputstream.adaptive-19.0.2.1.zip via install addon repository (¨*.zip)?

Not on Kodi 18
This is a temporary fix built just for testing. From what I've heard, I'm not sure the problem matches the solution i.e issue still happens anyway.

[rocktobe]

Hello,
I finally found a solution.
I managed to downgrade to widevine version 4.10.2252.0 via the method
curl https://k.slyguy.xyz/.decryptmodules/widevine/4.10.2252.0-linux-armv7.so | sudo tee /home/osmc/.kodi/cdm/libwidevinecdm.so >/dev/null
I just needed to change " /home/osmc/.kodi/cdm/libwidevinecdm.so " cause my directory was not located at the same place...
It works perfectly !

[DjDiabolik]

@DjDiabolik I personally haven't used the new Widevine, I typically turn off InputStream Helper's automatic updates and run it until it doesn't work.

CUT CUT
how it's possible to do this ? I need to put some addictional setting ?

[wagnerch]

how it's possible to do this ? I need to put some addictional setting ?

https://github.com/emilsvennesson/script.module.inputstreamhelper/wiki/Troubleshooting#disable-inputstream-helper

I usually go into InputStream Helper's settings and there is a "Disable InputStream Helper" setting. My experience is this will stop the "forced" updates (which I think is just a 30 day timer), you can also click "Cancel" if the pop-up comes asking to update (but that's annoying with every video).

IIRC, you can still Install/Reinstall/Rollback. Which is how I manage it, when something is broken with Widevine and reports suggest a new Widevine version then i'll go in an click "Install". It's a bit hard to know if it is Widevine or something else, but my experience with Netflix is 95% of the time it is something Netflix server-side changed and the add-on hasn't been updated yet.

[Stavr0sStuff]

On OSMC/Kodi 18 I found that I only needed to run:

sudo apt-get update
sudo apt-get install --only-upgrade libc6
curl https://k.slyguy.xyz/.decryptmodules/widevine/4.10.2252.0-linux-armv7.so | sudo tee /home/osmc/.kodi/cdm/libwidevinecdm.so >/dev/null
sudo reboot

I can confirm this has worked for me as well! Kodi 18.(Belgium, VRT.NU stopped working and now it works again)

Thanks!

[riess82]

worked for me as well on OSMC