Posts by HiassofT

  • Nightly Builds

    Quick heads up:

    We've now finally retired Generic-legacy and won't provide any updated LE13 image and addon builds for it anymore.

    If you were still using Generic-legacy please switch to Generic.

    so long,

    Hias

  • Development Support [RetroAchievements]

    I'd recommend building kodi, game.libretro and rcheevos with debug info and also enable the address sanitizer.

    You can pass in the needed options as environment variables when building LE, but personally I prefer to create a .libreelec/options file with them. eg:

    Code
    DEBUG="kodi game.libretro rcheevos"
DEBUG_SANITIZER_CFLAGS="-fsanitize=address -fno-omit-frame-pointer"

    Then do a full clean image and game.libretro addon build.

    The undefined behavior sanitizer can also be helpful - see the gcc docs https://gcc.gnu.org/onlinedocs/gcc…on-Options.html

    Another possibility is to run kodi with valgrind - it's a lot slower than the address sanitizer but may give additional info.

    To include valgrind in the image you need to enable it:

    Code
    VALGRIND="yes"

    and then manually start kodi with valgrind kodi --standalone -fs --audio-backend=alsa+pulseaudio

    Depending on where exactly it's crashing you may need to enable debug info for additional packages.

    so long,

    Hias

  • Nightly LE13: remote.xml not loaded

    Thanks for the info!

    This remote is a bit of a bitch (I have the Gmyle branded version here in a box), both the "i" button and the "right mouse" button generate the same button/keycode (BTN_RIGHT - right mouse button - which will bring up the context menu when you place the cursor at some entry).

    Previously we had remapped those two buttons to KEY_INFO via eventlircd, and I guess I should include the same mapping in LE13 - that remote was somewhat popular in the past.

    For now, please create a /storage/.config/hwdb.d/99-remote.hwdb file with the following content, then reboot.

    Code
    evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_90002=info

    Please report back if this works for you, too.

    so long,

    Hias

  • Nightly LE13: remote.xml not loaded

    Your remote seems to be generating a BTN_ instead of a KEY_ code for that button - that's problematic.

    What kind of remote is this? Is it an IR remote where you configured a ir-keytable in rc_maps.cfg? Or is it a remote with a USB / RF dongle or bluetooth?

    If it's an IR remote with ir-keytable/rc_maps.cfg config then the easiest solution is to just change that single code to a KEY_... keycode (look at /usr/lib/udev/rc_keymaps/rc6_mce.toml for the well supported KEY codes of the MCE remote).

    If it's an USB / RF / BT hid remote then you/we can remap that via a hwdb file:

    Install the System Tools addon from the LE repository, ssh in and post the content of /proc/bus/input/devices.

    Now stop kodi with "systemctl stop kodi".

    Then run "evtest", select the device matching your remote, push the button that didn't work in kodi and also post the full output. Some remotes expose multiple input devices, in that case go through them one-by-one and see which of them generates output on the button press.

    Please post the full output you got from evtest, including all the details it printed before waiting for the button press.

    Also please run "pastekodi" and post the URL you got.

    I'm currently collecting as much info as possible about all the remotes in use by our users to further improve kodi / LE - and that info will help me to decide if it's best to try to improve it in Kodi, or in LE, or if it's too special and it's best to guide users how they can fix it on their own.

    so long,

    Hias

  • Important change in LE13 remote handling

    Thanks to long-time joint effort work Kodi now has significantly improved input handling.

    This allowed us to finally drop the eventlircd workaround and use standard linux (lib)input handling for remotes, too.

    Currently LE13 images are building and the next nightlies will contain this change.

    One of the benefits is that Kodi now supports a lot more buttons/keys and the majority of the remotes should now work out-of-the-box.

    Another benefit of standard Kodi input handling is that you no longer need to fiddle around with Lircmap.xml or remote.xml to remap the buttons but can use the keymap editor addon from the kodi repo (or modify keyboard.xml).

    And this finally brings long-press support to remotes, too - which helps a lot if your remote has very few buttons. eg longpress-OK will open the context menu.

    As with every big change there will be some minor disruptions:

    If you previously adjusted the button mapping with remote.xml you'll now have to redo it.

    Even if you didn't change it the mapping may now be a bit different - just use the keymap editor addon to adjust it to your preferences.

    And although kodi now supports a lot more buttons it could be that your remote uses some keycodes that kodi doesn't support (yet).

    In this case we need your help so we can further improve Kodi and LibreELEC:

    Please tell us about the vendor and model of your remote and which buttons are not working and also post a kodi debug log:
    Enable debug logging in the kodi settings, then reboot, then just press the non-working keys and then upload the log - either by running "pastekodi" over ssh or with the log upload function in the LibreELEC settings - and post the URL to the log.

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    sebden no worries, you seem to have uncovered and interesting bug that likely existed for a long time but no-one noticed so far - and your logs and info were very helpful!

    Better go back to official nightlies, the washed-out colors are with HDR enabled are expected as your gen9 intel can't transmit the HDR infoframe.

    With HDR disabled (so kodi tonemaps HDR->SDR) the output should be identical in nightlies and smp's build.

    But signalling BT2020 for a HDR->SDR tonemapped image is still wrong, so the colors won't be correct, maybe oversaturated (likely both on your Sony and Samsung TVs) - that's something that needs to be fixed in kodi.

    While BT2020 colorspace with SDR gamma would be technically possible it's not a standard combination and it's hard to tell how TVs react to that - especially when the TV doesn't receive a HDR infoframe which would explicitly tell it the used EOTF - that's a bit of undefined territory.

    Your Sony seems to have received the (incorrect) BT2020 colorspace info correctly and shown "BT2020" to you and likely intepreted the BT709 data as BT2020. Not sure which EOTF it used, but if it had used PQ you'd likely have gotten over-bright white and in general a way to high contrast.

    Not sure about the Samsung, maybe it just didn't show you the BT2020 (or it's buried somewhere in deeper info pages).

    Nevertheless, if your PC didn't transmit the HDR infoframe and indicate PQ (or HLG) EOTF it's correct that the TV doesn't show "HDR".

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    I think I know now what's going on and it does look like a kodi bug to me:

    Even with a SDR display connected (which doesn't report support for BT2020) kodi sets the Colorspace connector property to BT2020 - and my HDFury also shows that in the received AVI infoframe.

    Code
    2026-06-15 19:59:50.957 T:935     debug <general>: virtual void KODI::WINDOWING::GBM::CWinSystemGbm::SetColorimetry(const VideoPicture*): setting connector colorspace to BT2020_RGB (source BT2020_YCC)

    But as the connector doesn't have the HDR_OUTPUT_METADATA property kodi it detects it as a SDR display and performs tonemapping:

    Code
    2026-06-15 19:59:50.957 T:935     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: off
...
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: Requested render method: 0
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard
2026-06-15 19:59:51.210 T:935      info <general>: GLES: Selecting YUV 2 RGB shader
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard

    I'm not familiar with the inner details of kodi's tonemapping implementation but I highly suspect that will do both PQ->gamma EOTF transformation and also BT2020->BT709 colorspace transformation.

    So I guess kodi outputs a standard BT709/gamma SDR image, but signals BT2020 colorspace which doesn't quite match.

    smp could you have a closer look at the kodi code?

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    Quote from smp

    The log shows that HDR passthrough is now enabled. If the TV does doesn't switch to HDR mode then the theory that HDMI 1.4 can output HDR metadata is wrong.

    Just for the kicks I gave your build a try on an ancient gen6 system and got the same result:

    The HDR_OUTPUT_METADATA connector property now appears on the HDMI connector, and kodi set it, but I get the same kernel splat as in the OP's log and my HDFury Vrroom didn't report any HDR metadata - so the infoframe wasn't generated (as expected from the kernel splat)

    so long,

    Hias

  • LE13, Intel Nuc running Xe (GPU driver) and foot (terminal); Bug ?

    Well, about 1 month ago heitbaum reported an issue with the xe driver during video playback with pretty much the same log message (in our slack channel):

    Code
    May 15 20:51:44.895554 nuc12 kernel: xe 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A][PLANE:33:plane 1A] fault (CTL=0x92001000, SURF=0x4000000, SURFLIVE=0x4000000)

    Your post rang a bell, and I guess that pretty much proves that the Xe driver is considered to be experimental for gen1 Xe.

    so long,

    Hias

  • Slice + CM4S - anyone have a working dt-blob.bin / image?

    IIRC the essential bit in the dtblob for ethernet is that you provide a (25MHz?) clock on GPCLK1

    The dtblob dts files for CM1 and CM3 that we shipped in LE are here:

    GitHub - LibreELEC/slice-firmware: BCM270x firmware related stuff for Slice
    BCM270x firmware related stuff for Slice. Contribute to LibreELEC/slice-firmware development by creating an account on GitHub.
    github.com

    And you can get the official RPi dts file from here (you'd need to drop all blocks except for the pins_cm4s block and then add pin and clock setup for GPCLK1):

    firmware/extra/dt-blob.dts at master · raspberrypi/firmware
    This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware. -…
    github.com

    The RPi forums is probably the best place to ask about details

    so long,

    Hias

  • LE13, Intel Nuc running Xe (GPU driver) and foot (terminal); Bug ?

    This is somewhat expected, the xe driver is for the Xe2 (and later) GPUs.

    Since you have a first gen Xe you need to use the i915 driver - just remove the force_probe options from your command line, the kernel will then automatically use the correct driver.

    Note that the kernel config explicitly mentions that support for first gen Xe in the xe driver is experimental:

    linux/drivers/gpu/drm/xe/Kconfig at master · torvalds/linux
    Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
    github.com
    Code
    config DRM_XE
    ...
	help
	  Driver for Intel Xe2 series GPUs and later. Experimental support
	  for Xe series is also available.

    so long,

    Hias

  • [RPi4] Headphone audio cracking/clipping on certain video steams

    H264 decoding, deinterlacing and analog audio output are all handled by the RPi's VC GPU - and deinterlacing HD video plus audio output is just too much.

    Go to Settings->Player, set settings level to Expert and disable "Allow hardware deinterlace with DRM PRIME".

    The RPi will then do deinterlacing in software (using BWDIF which will be higher quality, too) and free up enough GPU cycles for analog audio out.

    I strongly recommend though staying away from the on-board analog output on RPis, even a 3 EUR/USD USB audio adapter will have significantly better audio quality and cause fewer issues.

    so long,

    Hias