Posts by chewitt

How you configure something is about how to use the app, not how we packaged the app into an add-on.

I'd suggest to ask the question in https://tvheadend.org

taki Thanks for sharing the patches, they are interesting reading! .. once decrypted from Turkish to English

Some of the comments you've made are valuable. I was seeing an attach issue with MxL608 behind an AVL6762 i2c repeater when working on my O2.cz box, and while trial and error with Claude eventually figured out a "fix" and theorised an explanation, one of your comments explains the actual problem and better/correct solution.

Quote from Viking1

lt's been a very long time since a nightly build, version 12.2, for RPI5! How come?

There are no further Kodi 21 releases planned, and no further LE12.2 releases planned, so unless there's a random bump to some package (last one I can see was tz-data on 3rd March) nothing changes and there's no reason to build nightlies. There have been some bumps to add-on packages, but those are built/handled separately.

It doesn't matter how many log snippets you show us. The only real expertise on how widevine support works with Netflix is in the Kodi forum and not here.

Quote from Andulo Bui

"errorDisplayMessage": "This title is not available to watch instantly. Please try another title."

That probably means something to the Netflix add-on developer(s). It means nothing to me (see previous comment in post #2). The Netflix add-on support thread is in the Kodi forum, not here.

Your box does not use the Tyr driver so that has nothing to do with it.

I pushed my current working DVB patches branch to https://github.com/chewitt/linux/commits/dvb-7.0.y/

I pushed current AMLGX working image changes to https://github.com/chewitt/LibreELEC.tv/commits/amlogic

To make image packaging easier I have the Linux patchset I'm testing in projects/Amlogic/patches/linux and a separate set of DVB patches in packages/linux/patches/dvb as this makes it simple to regenerate each patchset independently (using a script) and then I can respin the image to test changes. Thanks to an ex-employer that went bust I'm lucky to have a 32x core build server so image respin time (only rebuilding the kernel) is around 2 mins; then I pull the image from the server to the current test device over scp and reboot to see what broke/changed/etc. and then give feedback to Claude. NB: If you ever wondered why I always hardcode a static version in all my test images; it means I can predict filenames on a remote server to make transfers easier.

Kodi does not ship binary add-ons for Linux because there's are too many different distros; so it's the responsibility of each distro that ships Kodi to also build and package the accompanying add-ons.

Hence LE has its own repo!

I can see 'stars' in our Generic Legacy repo: https://addons.libreelec.tv/12.2.0/Generic…eensaver.stars/

I cannot see it in Generic (non-Legacy) repo so perhaps it depends on X11 (only available in Legacy).

Ahh, rozpruwacz is Marek

I now have the DVB-S and DVB-T tuners for the WeTek Play2 and the DVB-T tuner in the O2.cz box showing up in Tvheadend. I am able to run a scan without errors. However I have no Satellite dish or Terrestrial antenna to connect them to so all scans find zero services (as expected) so it's impossible to tell whether anything is really working

I've pushed an updated set of images to my testing share. The WP2 image and 'box' image will boot the default WP2 device-tree which contains no DVB support, so you will need to edit extlinux.conf or uEnv.ini and change the dtb name to one of:

• meson-gxbb-wetek-play2-atsc.dtb <= might not work, I didn't find the ATSC tuner module to test yet
• meson-gxbb-wetek-play2-dvb-s.dtb
• meson-gxbb-wetek-play2-dvb-t.dtb

The O2.cz box (SML-5442TW) and the GTMEDIA GTT-2 box Marek has been using both have DVB support enabled.

Once WP2 is rebooted with the correct device-tree file dmesg should show the cards, and you can install Tvheadend43 (or VDR) to scan for services. I'm a bit vague on the remaining process as (as mentioned) I can't test anything.

rawnar I've also included a WeTek Hub image in the test share. Apologies for the long wait, I got a bit distracted.

Quote from kspore

If someone can say for sure though that their x86 install of libreelec 12.2.1 is working correctly with widevine L1 then it's prob just my setup specifically being borked

Widevine L1 requires a TEE (Trusted Execution Environment) and device-specific certification. The only hardware I'm aware of that supports this are ChromeOS devices; when running ChromeOS (not Linux). All other devices will be limited to L3 which restricts you to 720p or 1080p, depending on the service. The same is true for ARM SoC hardware; the device needs to support OP-TEE and the video pipeline needs to support interacting with secureworld. Although it is possible for L1 certification on ARM SoC hardware under Linux, it's rare and requires a hardware-specific distro, e.g. OSMC for their Vero devices. L1 is mostly only found on Android devices.

TL/DR: L1 is not supported on x86_64, only L3.

You'll need to create a debug image and use valgrind to understand more. Top doesn't show anything useful.

taki Interesting! .. but I would ask that you push current working code to a GitHub repo as it would make a lot of sense for Marek (and likely others) to collaborate on a clean demux rewrite that could eventually be upstreamed, than get too far down the road of reworking vendor code.

NB: I have been poking around in the vdec code recently and have one MPEG2 video that now decodes (badly) which I guess is an improvement on no videos decoding. I have a hunch the underlying issue is about alignment of buffers to frame dimensions, but neither I or Claude managed to spot the problem yet. It continues to be something I tinker with (among many things) though.

kodi.bin .. which isn't granular enough information to be useful .. and I will end up relying on others to hunt that kind of issue down as that kind of debugging isn't something I know how to do

The RPi5 image in my test share seems to work, although I also suspect there is a memleak somewhere so YMMV.

I see nVidia and Waipu and VPN and summise that whatever the issue is, I'm not the person to investigate it.

Using some initial work from https://github.com/mczerski - Claude and I (mostly Claude) have made some progress on mainline DVB support: https://paste.libreelec.tv/moving-lab.log .. the above is from a WeTek Play2 box.

Before anyone gets wildly excited, the vendor kernel demux driver that Marek started porting is a festering ifdef nightmare that looks like it needs a lot of work and I have no way to test DVB-C, DVB-T, or DVB-S things; so I have no clue if the now-showing-up adapters do more than look pretty. Marek appears to have more of a clue about DVB things than me so cross fingers

NB: I plan to dig out the DVB-S module for WP2 and an old O2.cz box that I have in a cupboard somewhere and get those working next. Once that's done I'll clean up the smorgasbord of patches, push branches to GitHub, and share some updated images.

Pairing and Trust are separate actions; IIRC both are needed