Posts by chewitt

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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.

  • Adding screensaver offline from ZIP file

    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).

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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.

  • [x86-64] Netflix errors with Widevine

    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.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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.

  • Rockpro64 images - no proper hdmi-sound

    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.

  • [RPi400] Memory leaks?

    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.

    /shrug

  • [x86-64] Connection issues of bluetooth headphones and buggy remote

    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

  • Supported SFP+ Cards

    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.

  • Rockpro64 images - no proper hdmi-sound

    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.

    /shrug