Posts by chewitt

  • [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

  • Supported SFP+ Cards

    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.

  • [RPi400] Memory leaks?

    The short answer is "no idea" and it's not guaranteed that what you see if the same as what I see. On my LE13 image there's 100% a bad leak, but I'm running a whole heap of experimental things that mess with DRM planes and buffers and I see the same leak on Amlogic and Rockchip (with the same patches) too. The fact nobody but you has complained before on LE12 is the main thing I find odd, as it's the kind of thing that would attract forum complaints.

    Either way, the LE13 patches need a load of reviewing and debugging and that's going to be my (Claude driven development) focus over the next week. Maybe that results in something..

  • Supported SFP+ Cards

    This is our kernel defconfig https://github.com/LibreELEC/Libr…nux.x86_64.conf

    Fibre NICs aren't a thing among our domestic userbase, hence there's probably little/no info on the topic, but that ^ file is where to cross-reference the NIC driver that's required for a specific device and whether it's enabled by default or would need to be enabled to work. Some NICs may also require firmware blobs but that can always be solved by dropping things in /storage/.config/firmware folders so they are overlaid on /usr/lib/firmware on next boot.

  • [x86] Videos playing in top left quadrant only

    See if adding video=HDMI-A-1:1920x1080M@60D to kernel boot params (change HDMI-A-1 to match the DRM connector used) solves the problem? - this will force the intial DRM state to 1080@60. As a general rule it's best to leave the Kodi GUI at 1080p and only switch to 4K when needed for playback, see: https://wiki.libreelec.tv/configuration/4k-hdr. I'll guess Kodi currently has a limit on the GUI being 1080p max but the desktop resolution or underlying kernel DRM layer is trying to use a 4K mode.

  • [RPi5] H.265 Stuttering

    If you are using the wrong presets when ripping or converting media, change the presets to ones that work on your hardware. If you are stealing the media off the internet and expect all the random encodings that have been used to work on all hardware; a) you will be dissapointed, and b) we don't care about that problem.