Posts by chewitt

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

CE (and old vendor kernel LE images) can boot between SD/eMMC in the GUI because the Amlogic u-boot environment where boot preferences are stored is accessible from Linux (via proprietary Amlogic drivers). There is no equivalent mechanism with mainline u-boot and Linux. NB: CE issues belong in the CE forum, we have no experience with it here.

I was checking whether it was a phone app remote as we suspect a leak via JSONRPC, but no.

Memory leaks are always a bitch to find unless the impacted end-user happens to be a software developer with some experience of using debugging and analysis tools. I am also seeing a leak (or leaks) but given the differences between your LE12 and my heavily patched LE13 version of Kodi, it's unlikely to be the same root cause.

YouTube will never be simple to install because Google charges for API based searches. The add-on embeds pre-configured API keys but these have a limited free search quota per 24h period and Kodi has a large userbase so the quota is exhausted within minutes of resetting. The cost of providing paid-for 'free' search for Kodi users would require considerably more revenue than the income Kodi generates from t-shirt sales and public donations. Kodi also has an open-source add-on ecosystem so if we funded API keys in the YouTube add-on, they are not secure and will be instantly stolen and reused by other apps and services (this already happens with the pre-configured ones) with their quota consumption charged to Kodi. If you want easier Google services, the only realistic option is to use the native apps on Android, as then Google provides free access to its own services because "If the service is free, You're the product" is one of the foundation principles of their business model.

For BT problems; delete the device and then redo pairing and (separate) trust using bluetoothctl from the CLI over SSH and see if that then works better. Headphones normally need pair/trust relationships.

If multiple phone apps aren't working, perhaps:

• There's a general issue within your network, e.g. multiple routers and incorrect subnet routing
• Common security or network settings on the phone, e.g. VPNs which route traffic down a tunnel
• There's an issue with config/settings on Kodi - I'd ask for debug logs but they're unlikely to show anything useful

You're posting your unnecessarily bolded text in the wrong forum. Our interest and [limited] expertise in Rockchip hardware is focussed on mainline/upstream codebases, not downstream vendor garbage, and we don't use Yocto/OE, and we loathe hiding things behind secureworld.

--- a/projects/Generic/linux/linux.x86_64.conf
+++ b/projects/Generic/linux/linux.x86_64.conf
@@ -2442,7 +2442,11 @@ CONFIG_SKY2=y
 # CONFIG_SKY2_DEBUG is not set
 # CONFIG_OCTEON_EP is not set
 # CONFIG_OCTEON_EP_VF is not set
-# CONFIG_NET_VENDOR_MELLANOX is not set
+CONFIG_NET_VENDOR_MELLANOX=y
+CONFIG_MLX4_EN=m
+# CONFIG_MLX5_CORE is not set
+# CONFIG_MLXSW_CORE is not set
+# CONFIG_MLXFW is not set
 # CONFIG_NET_VENDOR_META is not set
 # CONFIG_NET_VENDOR_MICREL is not set
 CONFIG_NET_VENDOR_MICROCHIP=y

Modules need to be baked into the image. Something like that ^ should enable CX311 support.

As a general rule we are okay to enable modules by default , but will want to:

• Know the specific modules that need to be enabled?
• Know if any firmware is required?
• Understand what the increase to default image size is?
• See some kind of proof of them working!

In short, user does the research on what's needed, then we can take it over in the long term. We are likely to refuse niche hardware requests if the modules and/or firmware are large in size; we care deeply about being a minimal distro and this is not maintained by adding driver/firmware bloat that only a single handful of users might ever use.

It's not hard to maintain a self-built image. As long as it works, there's no obligation to update and rebuild frequently.

Quote from kapqa

Upon boot there is sequence with "u-boot" logo on the right, and on left, there isl like "uboot 2023.1-dfsg-something from 2025 september or october" - am i right in assuming this is sort of firmware that possibly could be updated?

LE doesn't show any logos or u-boot info on-screen during board so this means the u-boot on eMMC is from some other distro, e.g. some kind of vendor u-boot/kernel Linux image. As a general rule you need to run vendor kernels with vendor u-boot, and mainline u-boot with mainline kernels, because although they are separate things; there's a degree of alignment between them and you will often see random issues when using vendor u-boot and mainline kernel, or vice versa.

If you want to keep the current Linux image on eMMC you might be able to investigate whether there are newer versions of u-boot for it; and whether those work better. If you obtained and wrote a mainline u-boot to eMMC this would probably boot LE better, but may cause issues for a vendor-kernel Linux image. You can also write an LE image to eMMC using emmctool from the console, but this will overwrite whatever Linux is on eMMC.

I've never used it myself, but see https://wiki.libreelec.tv/configuration/pulseaudio

As Linux dominates the server market where optical NICs are normal, it's unlikely that any NIC more than a year old is not supported in the kernel, although LibreELEC probably won't have the modules enabled.

The CONFIG_NET_VENDOR sections define the top-level support for NIC families, but the defconfig is hierarchical and most vendors have multiple NIC families so when you enable a specific family; only then are it's options exposed so the defconfig is never showing you all possible options for all possible modules. If you know the specific NIC hardware tracing the config for it is simple. If you are working with hypothetical hardware it's not.

Instructions on building an image: https://wiki.libreelec.tv/development/build-basics

Then edit the defconfig to enable the module (uncomment and use =m) based on either looking at the file or some Google/GPT research on what's needed, then re-run the build command and the kernel will be rebuilt with the module enabled. Then tranfer the image to /storage/.update and reboot to see if it worked.

Random Q .. what kind of remote control do you use?

What u-boot version/source is on the eMMC module? - If this is present it will be used even if the board subsequently boots KERNEL and SYSTEM from the SD card. If you remove it, then the board uses u-boot from the SD card.