Posts by adam.h.

  • [EXPERIMENT] LibreELEC → Yocto/BitBake Build Pipeline Migration

    I think there is a fundamental misunderstanding here of what Yocto actually is.

    Yocto is not a pre-built operating system or a standard Linux distribution where you just 'add a few missing media packages' on top. Yocto is an empty build engine framework. It provides the toolchain and the build mechanics, but it contains zero software packages of its own.

    To build any functional operating system with Yocto - let alone one as specific as LibreELEC - you have to write or port BitBake recipes for every single component, from systemd and the kernel configuration down to Kodi and its dependencies.

    Suggesting to 'start with Yocto and add only missing things' implies Yocto provides the rest out of the box. It doesn't. Porting the LibreELEC package set into Yocto recipes is exactly how a Yocto-based distribution is built from scratch.

    My experiment was a proof-of-concept showing how LibreELEC’s existing infrastructure could be translated into that framework. It wasn't about changing the software inside the distro - it was about changing the engine that compiles it.

  • [EXPERIMENT] LibreELEC → Yocto/BitBake Build Pipeline Migration

    The point of the project was simple: it started as a personal exercise to test the limits of Claude Code on a large, complex codebase. I chose LibreELEC precisely because its current build system is mature and contains over 5,000 recipes, making it an excellent real-world stress test.

    To answer your question: No, the goal wasn't to fork the distro or create a 'fake' LibreELEC. The goal was to see what LibreELEC’s exact package set, configurations, and architecture would look like if they were driven by a modern, industry-standard build system (Yocto/BitBake) instead of the current custom shell-and-stamp system.

    As for the name, calling the repository 'LibreELEC.new' was just a standard way to label a structural experiment on a LibreELEC codebase. It’s a proof-of-concept, not a rebranding campaign.

    Whether migrating the build pipeline to Yocto brings actual value to the LE community - via better host isolation, declarative feature toggles, or cleaner BSP layers - isn't for me to decide. I listed the theoretical technical benefits in my post, but it is entirely up to the core team and community to decide if those benefits are worth the massive migration cost.

    I’m just sharing the data and the code from the experiment in case anyone finds it useful.

  • [EXPERIMENT] LibreELEC → Yocto/BitBake Build Pipeline Migration

    Hey all,

    I wanted to share a personal experiment I've been running: an exploratory migration of the LibreELEC build pipeline to a Yocto/BitBake-based system.

    Repository: https://github.com/adam-aph/LibreELEC.new-30-March-2026.git

    The branch is based on the master libreelec.tv cut from March 30. This started as a private experiment - my excuse to work with Claude Code on a larger, real-world codebase - so temper expectations accordingly.

    🔧 WHY BOTHER?

    For those curious whether there's any genuine technical merit here (beyond "Yocto is what the cool kids use"), here's what actually changes for a codebase like LibreELEC:

    • Cryptographic task signatures replace fragile .stamp_* files
      Changing an ffmpeg configure option, patch, or dependency in package.mk triggers precisely the affected downstream packages (Kodi, gstreamer plugins, etc.) - no more volunteers reaching for rm -rf build.* to restore correctness, and no more PKG_NEED_UNPACK hacks.
    • sstate-cache gives reliable task-level binary reuse across machines and CI
      Tweaking one kernel config or driver only rebuilds the delta, instead of re-executing large chunks of the 5000+ recipe tree that the current linear stamp logic often invalidates unnecessarily.
    • Task-level DAG dependency modeling eliminates build races
      PKG_DEPENDS_TARGET + make -jN has inherent race conditions when multiple packages populate sysroot headers/libraries concurrently. BitBake replaces shell sequencing with mathematically enforced ordering, down to do_populate_sysroot vs do_configure.
    • Isolated native (-native) sysroots hermetically seal the toolchain and host tools
      cmake, pkg-config, sed, gawk, Python - all of it. This removes the occasional host contamination that leaks through the current packages/toolchain/ wrapper across varied volunteer distros (Arch, Ubuntu, NixOS, etc.).
    • Layer + bbappend architecture cleanly separates BSP/vendor specifics
      Device trees, kernel patches (RPi, Rockchip, Amlogic) and conditional logic move out of core packages/linux/ and packages/mesa/ into isolated vendor layers. Dropping an old SoC becomes a layer deletion rather than untangling shell if [ "$PROJECT" = ... ] blocks scattered across hundreds of package.mk files.
    • PACKAGECONFIG provides declarative, graph-aware feature toggles
      Global flags like pulseaudio, lirc, various codecs are automatically wired with their dependencies and configure flags across recipes - replacing the current manual threading of SUPPORT_*=yes through per-package shell conditionals in make_target() and options files.
    • module.bbclass and kernel-devsrc formalize out-of-tree driver builds
      Correct kernel tree preparation, KDIR, headers, and module packaging/stripping for WiFi dongles and proprietary drivers - instead of fragile sequencing scripts in packages/linux-drivers/ that depend on exact prior kernel unpack/configure timing.
    • Reproducible builds become an auditable property, not volunteer discipline
      sstate + the dependency graph make it easier to verify bit-identical images across machines without relying on stamp + shell environment assumptions.

    These are codebase-specific wins. That said - for a small volunteer team where the shell system is already well-understood, highly optimized for Kodi-centric embedded use, and operationally successful, the migration cost is massive. The strongest drivers are incremental correctness, host isolation, and long-term BSP maintainability as hardware targets grow.

    ⚠️ CURRENT STATE & CAVEATS

    • Converted 42 arch-variants across 28 PROJECT/DEVICE combinations.
    • Clean build achieved: libreelec-generic-x86-64 only
    • Not tested on any physical device (it will very likely fail)
    • Getting to a clean x86_64 build took roughly 100 hours working with Claude Code - this is not a weekend project

    🤔 IS THERE INTEREST?

    Honestly, I'm not sure this brings value for you - maybe it does. I'm sharing it in case someone sees potential here, or wants to pick it up.

    Realistically, continuing this properly would mean sponsored API tokens, access to physical hardware for testing, and significant time investment. That's essentially a part-time (or full-time) job, which isn't where I am right now.

    That said, I'm happy to discuss it. If you see value in this direction, think it's worth pursuing, or have thoughts on what "continued" would even look like in practice - feel free to DM me. No promises, but I'm not closing the door either.

    Cheers!

    Build:

    Result:

    Code
     303M May 22 14:30 LibreELEC-Generic.x86_64-12.0.img.gz
   1M May 22 14:30 LibreELEC-Generic.x86_64-12.0.img.gz.sha256
   1M May 22 14:30 LibreELEC-Generic.x86_64-12.0.manifest
 275M May 22 14:30 LibreELEC-Generic.x86_64-12.0.squashfs
   1M May 22 14:30 LibreELEC-Generic.x86_64-12.0.testdata.json
 549M May 22 14:30 LibreELEC-Generic.x86_64-12.0.wic
 303M May 22 14:30 LibreELEC-Generic.x86_64-12.0.wic.gz
   1M May 22 14:30 libreelec-image.env

    Complete Target Matrix - 42 arch-variants across 28 PROJECT/DEVICE combinations:

    PROJECTDEVICEARCHKERNELBOOTLOADERDISPLAYSERVERGRAPHIC_DRIVERSpatch_archNotes
    GenericGenericx86_64defaultsyslinuxnocrocus i915 iris r300 r600 radeonsi vmware virtiox86GBM/DRM; OpenGL=mesa
    GenericGeneric-legacyx86_64defaultsyslinuxx11crocus i915 iris radeonsi nvidia vmware virtiox86X11/Fluxbox; OpenGL=mesa
    Genericgbmx86_64defaultsyslinuxnocrocus i915 iris r300 r600 radeonsi vmware virtiox86GBM/DRM (same as Generic)
    Genericwaylandx86_64defaultsyslinuxwlcrocus i915 iris nvidia-ng r300 r600 radeonsi vmware virtiox86Wayland/Sway; OpenGLES=mesa
    Genericx11x86_64defaultsyslinuxx11crocus i915 iris radeonsi nvidia vmware virtiox86X11/Fluxbox; OpenGL=mesa
    RPiRPiarmraspberrypibcm2835-bootloadernovc4armRPi 1/Zero; arm1176jzf-s; KERNEL_TARGET=zImage
    RPiRPi2armraspberrypibcm2835-bootloadernovc4armRPi 2/3; cortex-a7; KERNEL_TARGET=zImage
    RPiRPi4aarch64raspberrypibcm2835-bootloadernovc4aarch64cortex-a72; KERNEL_TARGET=Image
    RPiRPi4armraspberrypibcm2835-bootloadernovc4aarch64arm32 on arm64 kernel; cortex-a53; TARGET_KERNEL_PATCH_ARCH=aarch64
    RPiRPi5aarch64raspberrypibcm2835-bootloadernovc4aarch64cortex-a76; KERNEL_TARGET=Image
    RPiRPi5armraspberrypibcm2835-bootloadernovc4aarch64arm32 on arm64 kernel; cortex-a53; TARGET_KERNEL_PATCH_ARCH=aarch64
    AmlogicAMLGXaarch64amlogicu-bootnolima panfrostaarch64cortex-a53; OPENGLES=mesa
    AmlogicAMLGXarmamlogicu-bootnolima panfrostaarch64arm32 on arm64 kernel; cortex-a53
    RockchipRK3288armdefaultu-bootnopanfrostarmcortex-a17; arm-only SoC
    RockchipRK3328aarch64defaultu-bootnolimaaarch64cortex-a53; ATF
    RockchipRK3328armdefaultu-bootnolimaaarch64arm32 on arm64 kernel; cortex-a53
    RockchipRK3399aarch64defaultu-bootnopanfrostaarch64cortex-a72.cortex-a53; ATF
    RockchipRK3399armdefaultu-bootnopanfrostaarch64arm32 on arm64 kernel; cortex-a72.cortex-a53
    RockchipRK356Xaarch64rockchipu-bootnopanfrostaarch64cortex-a55; LINUX=rockchip
    RockchipRK356Xarmrockchipu-bootnopanfrostaarch64arm32 on arm64 kernel; cortex-a55
    RockchipRK3576aarch64rockchipu-bootnopanfrostaarch64cortex-a72.cortex-a53; LINUX=rockchip
    RockchipRK3576armrockchipu-bootnopanfrostaarch64arm32 on arm64 kernel
    RockchipRK3588aarch64rockchipu-bootnopanfrostaarch64cortex-a76.cortex-a55; LINUX=rockchip
    RockchipRK3588armrockchipu-bootnopanfrostaarch64arm32 on arm64 kernel
    AllwinnerA64aarch64defaultu-bootno(mesa via OPENGLES)aarch64cortex-a53; ATF+crust
    AllwinnerA64armdefaultu-bootno(mesa via OPENGLES)aarch64arm32 on arm64 kernel; cortex-a53
    AllwinnerH2-plusarmdefaultu-bootno(mesa via OPENGLES)armcortex-a7; arm-only; UBOOT_FIRMWARE=crust
    AllwinnerH3armdefaultu-bootno(mesa via OPENGLES)armcortex-a7; arm-only; UBOOT_FIRMWARE=crust
    AllwinnerH5aarch64defaultu-bootno(mesa via OPENGLES)aarch64cortex-a53; ATF+crust
    AllwinnerH5armdefaultu-bootno(mesa via OPENGLES)aarch64arm32 on arm64 kernel; cortex-a53
    AllwinnerH6aarch64defaultu-bootno(mesa via OPENGLES)aarch64cortex-a53; ATF+crust (sun50i_h6)
    AllwinnerH6armdefaultu-bootno(mesa via OPENGLES)aarch64arm32 on arm64 kernel; cortex-a53
    AllwinnerR40armdefaultu-bootno(mesa via OPENGLES)armcortex-a7; arm-only; no ATF
    NXPiMX6armdefaultu-bootnoetnavivarmcortex-a9; arm-only
    NXPiMX8aarch64defaultu-bootnoetnavivaarch64cortex-a53; ATF+firmware-imx
    NXPiMX8armdefaultu-bootnoetnavivaarch64arm32 on arm64 kernel; cortex-a53
    QualcommDragonboardaarch64defaultu-bootnofreedrenoaarch64cortex-a53; mkbootimg host tool
    QualcommDragonboardarmdefaultu-bootnofreedrenoaarch64arm32 on arm64 kernel; cortex-a53
    ARMARMv7armdefaultu-bootnolimaarmGeneric ARMv7 reference; cortex-a8
    ARMARMv8aarch64defaultu-bootnolimaaarch64Generic ARMv8 reference; cortex-a53
    ARMARMv8armdefaultu-bootnolimaaarch64Generic ARMv8 reference; arm32 on arm64 kernel
    SamsungExynosarmsamsungu-bootnopanfrostarmcortex-a15.cortex-a7; LINUX=samsung

  • [RPi4] WiFi link "fails"

    Start with logs, Duncan - because blind guessing is for amateurs, and you've got a Pi that's playing hard to get.

    Enable debug logging in Kodi: Settings > LibreELEC > System > Logging > Toggle it on, then reboot and reproduce the WiFi flop.

    SSH in (root/libreelec) and run journalctl -u connman for network manager moans - look for DHCP fails, disconnections, or beacon losses.

    Peek at dmesg | grep brcmfmac for WiFi driver drama; signal issues or power-saving quirks often lurk there.

    If it's the passphrase loop, check signal strength in Connections settings - weak sauce triggers that nonsense.

    Router side: Log in, tweak channels to 1,6,11, and reboot it - interference is a sneaky bastard.

    Disable WiFi power save: SSH echo "options brcmfmac power_save=0" > /storage/.config/modprobe.d/disable-wifi-powersave.conf and reboot.

    Bump 'Wait for Network' to 30-60s in Services to give it breathing room.

    If logs scream hardware, ditch onboard WiFi for a USB dongle - Pi's antenna is about as reliable as a chocolate teapot.

    Forums with your logs if stuck; now go fix it before your Pi ghosts you permanently.

  • Slice4s

    Grok provides a few clues - and perhaps not all of them are pure nonsense:

    Diagnose via Logs and ALSA Status (Quick Root Cause Identification):

    • Run dmesg | grep -iE 'snd|alsa|audio|codec|i2s|underrun|overrun|error' and check your Kodi log (grep -i audio elegant-marmot.log).
    • Enable xrun debug: echo 1 > /proc/asound/card0/pcm0p/xrun_debug, play audio, then cat /proc/asound/card0/pcm0p/xrun_debug to confirm underruns (common for periodic glitches).
    • Test basic playback: speaker-test -c2 -r48000 -fS16_LE -Dhw:0,0—note if glitches align with 4s intervals or CPU spikes (top in parallel).
    1. Verify and Adjust ALSA Devices/Volumes (Fix Mismatches):
      • List devices: aplay -l (ensure your Slice card shows up).
      • Use alsamixer -c0 to unmute/adjust volumes (e.g., DAC controls); test formats/rates with speaker-test variants (e.g., -r44100 if 48kHz distorts).
      • In Kodi settings: Set audio device to "ALSA: hw:0,0" and disable passthrough if enabled.
    2. Tweak Boot Config and Reload Driver (Address Hardware/Timing):
      • Edit /flash/config.txt (remount rw): Add dtparam=i2s=on, hdmi_force_edid_audio=1 (if HDMI-related), and your overlay (dtoverlay=slice-audio or from repo).
      • Reload module: rmmod <your_module e.g. snd_soc_slice> && modprobe <your_module>.
      • Reboot and retest; if periodic, add audio_pwm_mode=0 to config.txt for PWM cleanup.
    3. Increase Buffers in Driver Source (Target Underruns/Periodic Glitches):
      • In your driver code (slice-drivers/sound/soc/...), bump snd_pcm_hardware values: Set buffer_bytes_max = 256 * 1024; and period_bytes_min = 8192;.
      • Recompile/install the module, reload, and test playback. Add debug prints in hw_params to log rates/channels via pr_info.
      • If clock-related, update DT overlay clocks (e.g., clock-frequency = 12288000; for 48kHz), recompile DTBO, apply.
    4. Hardware/Power Check and Fallback Test (Rule Out Environmentals):
      • Monitor voltage: vcgencmd measure_volts during playback—ensure stable 5V; swap PSU if dips.
      • Test on kernel 5.x stock image to isolate v6 porting bugs; if persists, probe I2S pins if hardware access allows.

    If these don't resolve, the issue may need kernel rebuild with SND_DEBUG_VERBOSE or forum help with logs/code snippets.

    but wait, chatGPT has its opinion as well ;)

        1. Quick confirm: xrun / underrun check

    Code
    # as root echo 1 > /proc/asound/card0/pcm0p/xrun_debug
# reproduce the glitch, then: cat /proc/asound/card0/pcm0p/xrun_debug
dmesg | grep -iE 'snd|alsa|audio|i2s|underrun|xrun|error'

    If xruns or pointer/avail errors show → underrun / pointer problem (go to step 3). If nothing shows → skip to step 4 (clocks).

    2. Quick behavior probe: speaker-test with bigger buffers

    Code
    speaker-test -c2 -r48000 -fS16_LE -D hw:0,0         # default
speaker-test -c2 -r48000 -fS16_LE -D hw:0,0 -p 8 -n 4   # larger periods/buffer
speaker-test -c2 -r44100 -fS16_LE -D hw:0,0         # try 44.1k

    If large buffers remove the glitch → it's an underrun/period-size alignment issue. Proceed to step 3.

    3. Fast driver fixes that often cure periodic glitches

    • Increase safe defaults in struct snd_pcm_hardware (temporary test):
    Code
    .buffer_bytes_max = 256*1024,
.period_bytes_min  = 8192,
.period_bytes_max  = 64*1024,
.periods_min       = 2,
.periods_max       = 8,
    • Force period alignment to frame size when computing period bytes:
    Code
    /* ensure period_bytes is multiple of bytes_per_frame */
period_bytes = frames * bytes_per_frame;
period_bytes = ALIGN(period_bytes, bytes_per_frame);

    Rebuild & test. If fixed, reduce sizes until minimal stable values.

    4. If xruns NOT present — verify clocks / DT overlay

    • Inspect device tree and confirm MCLK / clock-frequency exists for the codec.
    Code
    # inspect DT
grep -R "sound" -n /proc/device-tree || true
dtc -I fs -o - /proc/device-tree | less
dmesg | grep -i clock

    If MCLK or clock-frequency is wrong/missing → fix overlay to supply correct clock phandle/rate (e.g. 12.288 MHz for 48k×256 or the codec’s expected MCLK).

    5. Instrument pointer & hw_params for precise diagnosis
    Insert compact logs in hw_params() and pointer():

    Code
    pr_info("slice: hw_params rate=%u ch=%u frame=%u buf=%lu per=%lu\n",
        params_rate(r), params_channels(r), bytes_per_frame,
        r->buffer_size, r->period_size);
pr_info("slice: pointer dma_pos=%llu\n", (unsigned long long)dma_hw_ptr);

    Rebuild, run, and watch dmesg for pointer jumps or negative avail — that points to DMA position read / 64-bit type bug.

    6. Search/patch common porting gotchas (aarch64 / kernel-6)

    • Make sure DMA position and counters use u64/dma_addr_t properly (no implicit 32-bit truncation).
    • Use proper register reads (readl() / ioread32() as appropriate).
    • If codec probe fails for clocks, return -EPROBE_DEFER rather than continuing.

    7. If still failing — rapid triage steps

    • Try older kernel (5.x) image to confirm regression from kernel-6 port.
    • Paste pointer(), trigger(), and hw_params() here and I’ll mark exact lines to change.

    Short diagnosis summary

    If large buffer sizes fix it → underrun/period alignment; if no xruns and logging shows pointer discontinuities → DMA pointer / 64-bit type bug; if no pointer issues but glitch remains → clock/MCLK.

    and here comes the Gemini :D

    The root cause of the regular 4-second audio glitch is a hardcoded Master Clock (MCLK) in your driver. It's correctly configured for audio at $44.1 \, \text{kHz}$ but is incorrect for the very common $48 \, \text{kHz}$ rate, causing a predictable clock drift that the system violently corrects every few seconds.

    Here's the direct path to fixing it.

    Step 1: Confirm the Diagnosis (2-Minute Test)

    Force Kodi to resample all audio to the one rate your driver handles correctly: $44.1 \, \text{kHz}$. This requires no recompiling.

    1. SSH into your LibreELEC box.
    2. Create or edit the file /storage/.kodi/userdata/advancedsettings.xml.

    3. Add the following content:

      Code
      <advancedsettings>
  <audio>
    <samplerate>44100</samplerate>
  </audio>
</advancedsettings>
    4. Reboot the system (reboot).

    Play some audio, especially UI sounds or video files that are likely $48 \, \text{kHz}$. If the distortion and periodic glitches are gone, this confirms the MCLK is the problem. You can now proceed to the permanent fix.

    Step 2: Implement the Permanent Fix (Code Change) ✅

    Modify the driver to calculate the MCLK dynamically based on the requested sample rate instead of using a hardcoded value.

    1. Open your driver source file: sound/soc/bcm/slice.c.
    2. Navigate to the slice_hw_params function.
    3. Replace the hardcoded MCLK logic with a dynamic calculation.

    Change this section:

    Code
    	/* Set the codec system clock */
	err = snd_soc_dai_set_sysclk(codec_dai, WM5102_SYSCLK_MCLK1,
				MCLK_RATE, SND_SOC_CLOCK_IN);

    To this:

    1. Recompile your driver and the kernel, create the new image, and deploy it.
    2. (Optional but recommended) Remove the advancedsettings.xml file you created in Step 1.

    This code change has a very high probability of permanently resolving the audio issue for all standard sample rates.

  • [x86-64] Higole Gole 2 Pro

    Grok4 went and got itself some extra neurons, so here’s its hot takes. Might not be complete trash, who knows? :D

    Grok4:

    From the system details you provided (which appear to be from a Ubuntu-like distro, not LibreELEC, based on the kernel version and module list), the hardware is detected:

    • Touchscreen: Goodix capacitive over I2C (driver: goodix_ts.ko).
    • Accelerometer: MXC4005 (driver: mxc4005.ko).
    • Both modules are loaded in your current setup, but if they're not functioning (e.g., no input events), it could be due to missing firmware, I2C bus probing issues, or calibration.

    LibreELEC's filesystem is read-only (squashfs), so you can't simply "install" drivers like in a full distro. Instead, you'll need to build a custom LibreELEC image with the drivers enabled in the kernel. This is straightforward if you follow the steps below. I'll assume you're starting from a clean LibreELEC install on your device (download the Generic-x86_64 image from libreelec.tv/downloads and boot/install via USB). If you're currently on Ubuntu, switch to LibreELEC first for testing.

    Step 1: Verify Hardware Detection in Stock LibreELEC
    Before building custom, test if the drivers are partially working in a standard LibreELEC install:

    1. Install LibreELEC 12.x (or latest nightly) Generic x86_64 on a USB drive or your internal storage (eMMC via /dev/mmcblk0).
    1. Boot into LibreELEC and enable SSH (Settings > LibreELEC > Services > SSH).
    1. SSH in (default user: root, password: libreelec).
    1. Check for devices:
    • Code
      lsmod | grep goodix

      (for touchscreen).

    • Code
      lsmod | grep mxc4005

      (for accelerometer).

    • Code
      dmesg | grep -i goodix

      and

      Code
      dmesg | grep -i mxc4005

      for load errors.

    • Code
      evtest

      to list input devices and test touch/accel events (if evtest isn't available, it's because these modules aren't in the stock image).

    • Code
      i2cdetect -l

      to list I2C buses; then

      Code
      i2cdetect -y <bus_number>

      (try buses 0-3 based on your serial controllers) to see if the Goodix (usually at address 0x5d) or MXC4005 (address 0x15) shows up.

    If the modules aren't present (likely), proceed to custom build.

    Step 2: Build Custom LibreELEC with Drivers Enabled
    You'll need a Linux build host (e.g., Ubuntu 22.04+ VM with at least 4 cores, 8GB RAM, 50GB free space). This enables the drivers as kernel modules.

    1. Set Up Build Environment:
    • Install dependencies:
      Code
      sudo apt update && sudo apt install git gcc g++ make ncurses-dev bc lzop libssl-dev flex bison qemu-utils java-runtime-headless dosfstools

      .

    • Clone LibreELEC repo:
      Code
      git clone https://github.com/LibreELEC/LibreELEC.tv.git

      .

    • Checkout the branch for your version (e.g.,
      Code
      cd LibreELEC.tv && git checkout 12.0

      for stable, or master for nightly).

    1. Enable the Drivers in Kernel Config:
    • The kernel config is in
      Code
      packages/linux/linux.conf

      (for Generic x86_64).

    • Edit
      Code
      packages/linux/package.mk

      to add a patch for config changes.

    • Create a patch file
      Code
      packages/linux/patches/linux-0001-enable-goodix-mxc4005.patch

      with contents:

    • Replace
      Code
      XXXX

      with actual line numbers—extract the default config first by running a partial build (see below) and checking

      Code
      build.LibreELEC-Generic.x86_64-*/linux-*/.config

      .

    1. Build the Image:
    • Run:
      Code
      PROJECT=Generic ARCH=x86_64 make image

      .

    • This takes 1-2 hours. Output is in
      Code
      target/

      (e.g., LibreELEC-Generic.x86_64-12.0.0.img.gz).

    • Write the .img to USB:
      Code
      dd if=LibreELEC-Generic.x86_64-12.0.0.img of=/dev/sdX bs=4M conv=fsync

      (replace /dev/sdX with your USB device).

    1. Install and Test:
    • Boot the custom image on your GOLE2 Pro.
    • SSH in and load modules if not auto-loaded:
      Code
      modprobe goodix_ts

      and

      Code
      modprobe mxc4005

      .

    • Check
      Code
      dmesg

      for errors. If Goodix fails with firmware issues, it may need a binary firmware blob—copy from your Ubuntu setup (

      Code
      /lib/firmware/goodix_*.bin

      ) to

      Code
      /storage/.config/firmware/

      in LibreELEC and reboot (per LibreELEC wiki).

    • Test touch:
      Code
      evtest /dev/input/eventX

      (find the Goodix event).

    • Test accel:
      Code
      evtest /dev/input/eventY

      or

      Code
      cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw

      (adjust device number).

    Step 3: Enable Touch in Kodi

    • Kodi supports touch natively, but ensure:
    • Settings > Interface > Skin > Configure skin > Enable touchscreen mode.
    • If calibration is off, use
      Code
      ts_calibrate

      (if available) or edit

      Code
      /storage/.kodi/userdata/guisettings.xml

      for touch params.

    • For multi-touch gestures, it should work once the driver is loaded.

    Step 4: Enable Auto-Rotation (Flip)

    • Accelerometer provides orientation data via IIO.
    • LibreELEC/Kodi doesn't auto-rotate by default (no desktop manager like GNOME).
    • Install the "Screen Orientation" addon from Kodi repo (if available) or script it:
    1. SSH in, install Python if needed (via unofficial addons or custom build).
    1. Create a script
      Code
      /storage/.kodi/userdata/autoexec.py

      :

    • This monitors accel and flips Kodi's GUI. Test thresholds with
      Code
      cat /sys/bus/iio/devices/iio:device*/in_accel_*_raw

      .

    • For GBM rotation, if needed: Edit
      Code
      /flash/extlinux.conf

      to add

      Code
      video=DSI-1:panel_orientation=upsidedown

      or similar, but test.

    Troubleshooting

    • If I2C not probing: Add kernel params in
      Code
      /flash/extlinux.conf

      (append line:

      Code
      i2c_dev i2c_hid.polling=1

      ).

    • Build errors: Check logs in
      Code
      build.LibreELEC-*/

      . If kernel patch fails, manually edit the config during build (pause at menuconfig:

      Code
      PROJECT=Generic ARCH=x86_64 ./scripts/build linux:menuconfig

      ).

    • If modules load but no events: Check ACPI tables (
      Code
      acpidump

      ) for HID overrides; might need a DSDT patch (advanced).

    • Performance: N5095 has UHD Graphics; enable VAAPI in Kodi for hardware decoding (Settings > Player > Video > Allow hardware acceleration - VAAPI).
    • Community: Post your build logs on the LibreELEC forum (your recent thread there is a good start) for x86-specific help.

    If this doesn't resolve it, provide dmesg output from LibreELEC.

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