Posts by adam.h.

  • Nightly Builds

    Did you notice that several builds are picking up the same commit hash? Is it normal? Few examples:

    Code
    LibreELEC-Generic.x86_64-13.0-nightly-20250626-c1e526c.img.gz (sha256)	2025-06-26 17:08	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250627-c1e526c.img.gz (sha256)	2025-06-27 09:57	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250628-c1e526c.img.gz (sha256)	2025-06-28 07:18	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250628-e7d7252.img.gz (sha256)	2025-06-28 23:25	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250630-fa3ad4b.img.gz (sha256)	2025-06-30 16:49	279.7M
LibreELEC-Generic.x86_64-13.0-nightly-20250701-fa3ad4b.img.gz (sha256)	2025-07-01 15:58	279.7M

  • Nightly Builds

    Quote from chewitt
    Code
    kernel: nvidia-modeset: ERROR: GPU:0: Timed out waiting for core channel idle.

    No idea what that is .. Google doesn't show anything useful.

    ChatGPT ^^:

    1. Check Kernel Compatibility

    The 6.12 kernel may be ahead of NVIDIA’s QA validation curve. Try running with a more conservative, supported kernel version like 6.6.x LTS or 6.7.x to verify stability.

    2. Patch the NVIDIA Kernel Module for Compatibility

    If you must use 6.12, verify that the DKMS or manual installation succeeded without warnings. Run:

    Code
    dmesg | grep -Ei 'nvidia|gpu'
dkms status

    Check /var/lib/dkms/nvidia/570.144/build/make.log for errors. If there are symbol mismatches or KMS hook issues, NVIDIA may not yet support 6.12, and you may need to:

    • Use a community patch set (e.g., from NV-Kernel-Patcher if using open kernel modules)
    • Or manually adapt the build if the symbol changed (common with drm API updates).

    3. Test Disabling DRM KMS for Isolation

    Set in modprobe:

    Code
    echo "options nvidia-drm modeset=0" | sudo tee /etc/modprobe.d/nvidia.conf
sudo update-initramfs -u

    Reboot and see if the timeout disappears. This will narrow the issue to modeset interaction with the new kernel's DRM layer.

    4. Enable Early KMS Logging

    For deeper kernel debugging, append this to your GRUB:

    Code
    GRUB_CMDLINE_LINUX_DEFAULT="nvidia_drm.modeset=1 nvidia.NVreg_RegistryDwords=RmLogonRC=0xff"

    Then run:

    Code
    sudo update-grub && reboot

    Watch dmesg output for RmLogonRC flags — this can help pinpoint which channel stalls.

    5. Run with Open Kernel Modules (Optional)

    Since R515, NVIDIA supports open kernel modules:

    Code
    modinfo nvidia | grep filename

    ============================================================================================================
    ============================================================================================================
    ============================================================================================================

    and here some suggestions tailored to LE nighties (I'm wondering how much it all makes sense) :):

    1. Add NVIDIA DRM Modeset Boot Option

    LibreELEC lets you append kernel params via cmdline.txt on the /flash partition (accessible from SSH or directly from the SD card/USB):

    Code
    nvidia_drm.modeset=0

    💡 Purpose: Disables DRM modesetting which causes timeout in some nightly builds.

    Quote

    ✅ Highly recommended as first fix to isolate the nvidia-modeset stall.

    2. Force Legacy Rendering Path (X11 instead of GBM) — if available

    Some builds may allow fallback to X11 rendering using the x11 variant of the NVIDIA driver.

    From SSH, check if GBM is active:

    Code
    cat /var/log/Xorg.0.log | grep -i nvidia
cat /run/libreelec/debug/udev.log | grep -i gbm

    If GBM + KMS is the cause, switching to legacy X11 (if supported in this build) can reduce stalls — but not all LibreELEC nightlies retain this support.

    3. Check for Nouveau Conflicts

    Even though LibreELEC is minimal, you can verify nouveau isn’t mistakenly loaded:

    Code
    lsmod | grep nouveau

    If present, blacklist it permanently via /flash/syslinux.cfg or /flash/extlinux/extlinux.conf (depends on build):

    Code
    append boot=UUID=... quiet modprobe.blacklist=nouveau

    4. Set NVIDIA Power Management Policy

    Add to your cmdline.txt (or bootloader config):

    Code
    nvidia.NVreg_EnableGpuFirmware=0

    In some cases, firmware-based runtime power management causes timing problems on newer kernels.

    5. Enable Persistenced (if supported)

    LibreELEC often omits nvidia-persistenced, but if present:

    Code
    systemctl start nvidia-persistenced

    If not present, ignore — this is only effective in systems that use persistent GPU state management.

  • Subtitle Setup for a Specific Language

    Quote from Albert

    I still haven't found a solution to this problem.

    I had opposite problem with subtitles, always wanted to have original audio but specific subtitles language plus ignore forced subtitles if exists - ended up with creating my own little plugin for this :D

    Anyways, if current (updated) settings in Kodi aren't working for you, you can install Language Preference Manager plugin, which has zillion of options so some settings here should fix your problem.

  • Nightly Builds

    Quote from chewitt

    If you want more changelog info please go look at the full/original commit log on GitHub. We have no plans to bloat page load times and increase webserver load with more commit data that likely few people read.

    Yeah, right - we are listing as for now 145 build images (starting from May 2024) and only 20 past commits, no bloating at all, just perfect excuse for someone not getting work done?

    Nah, that would be just stupid to keep both in sync (say past 20 builds + 20 commits) ^^

  • Usb Hard drive not recongize since 11.0.4

    Quote from Marcin

    Is force mounting going to fix errors from LE?

    It won't fix anything, just mount it regardless these errors. The other (maybe better) option is to fix the disk in Windows system and change LE to mount it always as RO (the above url to autostart is good reference for details).

    BTW, the option to mount external contents disks as RO could be good extension for LE, but perhaps it happens so rarely that it is not worth the effort. I'm using RPi5 with latest LE12 and SSD disk formatted as NTFS and while I had that "dirty disc" errors in the past (probably around LE10 or LE9), it works now without problems. So this could be also some combination of disc type, NTFS and LE version (driver version).

  • NUC10 + LE13 + HEVC

    Oh sure, just be patient enough and all the problems will magically solve themselves! 😀

    With the following nightly LE release I can play above stream without problems:

    However someone with fresh eye catched up that it originally failed on HEVC stream and now it is openning H264 stream, so perhaps Kodi in this version has different preferences - not sure if H264 stream was available originally or was added later by Disney...

  • Nightly Builds

    Guys, could you make the changelog table a bit longer to cover all available nightly builds? For example, in Generic LE13, I have builds from May to September, but the changelog only shows releases from mid-July.

    I discovered that LE13 01416e0 is not handling subtitles properly, so I had to downgrade to a randomly chosen build from July 20, as the latest changelog entry only shows releases from July 25.

    I know I could spend time looking directly on GitHub, but why not make these pages a little more useful? :)

  • NUC10 + LE13 + HEVC

    Some more forensic analysis :D

    Here are the stream properties:

    Suprisingly it plays well from the file, even with enabled vaapi, and the same content fails with vaapi when it is streamed. See attached 2 screenshots from playing file and playing the stream.

    So perhaps the problem is not really in ffmpeg or drivers/kernel, but somewhere between InputStream Adaptive / Disney+ Addon / FFMpeg?

    EDIT: I forgot to add log file.

  • NUC10 + LE13 + HEVC

    Ok, so to complete this journey here is the log with Linux version 6.10.0-rc3 and FFmpeg version 6.1.1, the stream is not playable when hardware acceleration is enabled.

    Let me know if you think I can contribute with anything else.

  • NUC10 + LE13 + HEVC

    I'm using that setup: <setting id="debug.setextraloglevel">128,2048,32768,262144</setting> so ffmpeg is covered. I didn't try with ffmpeg 6.1.1 though.

    I tried that sample file attached to 23699 and it works fine for both software codec and hardware acceleration, see the log. As expected, with vaapi enabled it plays very smoothly, while it slightly stutters with software codec.

    So I suppose it is something else im my stream which causes these issues.