Posts by HiassofT

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:

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:

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

Quote from Marcin

Does anyone know a way to retrieve it? Can I just set a new one in Libreelec without knowing the old one?

Just open Settings->LibreELEC->Services and you can see the current username/password and set a new one if you like.

so long,

Hias

Quote from lomion

It worked! Thank you for your support!

Worth mentioning: The space in the second line is important!

Yes, it is

And thanks for reporting back,!

We've added the change to LE13 and it will be included in the next nightly (hopefully tomorrow).

You can delete the file after you updated.

so long,

Hias

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.

evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_90002=info

Please report back if this works for you, too.

so long,

Hias

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

Hard to tell without a log, but please read here: Important change in LE13 remote handling

so long,

Hias

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

Quote from Eli2k

Thanks, it works pretty well
now we need Retrodeck to make the experience perfect

Feel free to give it a try and report back if it works (note: according to the flathub page it's not available for aarch64, only x86_64 is listed).

ssh in and run "flatpak install flathub net.retrodeck.retrodeck", then try to start it directly from the flatpak addon.

so long,

Hias

sebden a fix for the incorrect BT2020 signalling when tonemapping is enabled is included in the latest nightly. Please give that a try

https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260622-50e20d4.img.gz

so long,

Hias

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

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.

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:

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

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)

[   57.150415] i915 0000:00:02.0: [drm] *ERROR* [CRTC:59:pipe A] mismatch in infoframes.enable (expected 0x000000f1, found 0x00000071)
[   57.150423] i915 0000:00:02.0: [drm] *ERROR* [CRTC:59:pipe A] mismatch in drm infoframe
[   57.150426] i915 0000:00:02.0: [drm] *ERROR* expected:
[   57.150428] i915 0000:00:02.0: HDMI infoframe: Dynamic Range and Mastering, version 1, length 26
[   57.150431] i915 0000:00:02.0: length: 26
[   57.150433] i915 0000:00:02.0: metadata type: 0
[   57.150434] i915 0000:00:02.0: eotf: 2
[   57.150436] i915 0000:00:02.0: x[0]: 34000
[   57.150438] i915 0000:00:02.0: y[0]: 16000
[   57.150440] i915 0000:00:02.0: x[1]: 13250
[   57.150441] i915 0000:00:02.0: y[1]: 34500
[   57.150442] i915 0000:00:02.0: x[2]: 7500
[   57.150444] i915 0000:00:02.0: y[2]: 3000
[   57.150445] i915 0000:00:02.0: white point x: 15635
[   57.150447] i915 0000:00:02.0: white point y: 16450
[   57.150448] i915 0000:00:02.0: max_display_mastering_luminance: 1000
[   57.150450] i915 0000:00:02.0: min_display_mastering_luminance: 200
[   57.150451] i915 0000:00:02.0: max_cll: 0
[   57.150453] i915 0000:00:02.0: max_fall: 0
[   57.150454] i915 0000:00:02.0: [drm] *ERROR* found:
[   57.150458] ------------[ cut here ]------------
[   57.150459] i915 0000:00:02.0: [drm] pipe state doesn't match!
[   57.150460] WARNING: drivers/gpu/drm/i915/display/intel_modeset_verify.c:225 at intel_modeset_verify_crtc+0x323/0x540, CPU#0: kodi.bin/792
[   57.150467] Modules linked in: 8021q bnep ntfs bluetooth ecdh_generic ecc snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic snd_soc_avs snd_soc_hda_codec intel_rapl_msr snd_hda_ext_core intel_rapl_common snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core x86_pkg_temp_thermal intel_powerclamp snd_hwdep cfg80211 rfkill pkcs8_key_parser fuse dmi_sysfs
[   57.150495] CPU: 0 UID: 0 PID: 792 Comm: kodi.bin Not tainted 7.1.0 #1 PREEMPT 
[   57.150499] Hardware name: HP HP EliteDesk 800 G3 DM 65W/829A, BIOS P21 Ver. 02.50 07/14/2024
[   57.150501] RIP: 0010:intel_modeset_verify_crtc+0x329/0x540
[   57.150504] Code: 77 9a fe 48 85 ff 74 04 48 8b 7f 08 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 94 75 11 00 48 8d 3d 8d 2c ae 0b 4c 89 e2 48 89 c6 <67> 48 0f b9 3a 48 c7 c2 95 1d d7 b0 31 f6 4c 89 f7 e8 91 23 f9 ff
[   57.150507] RSP: 0000:ffffb82601503a58 EFLAGS: 00010282
[   57.150510] RAX: ffffffffb0d7652b RBX: ffff9be4d141f000 RCX: 0000000000000027
[   57.150512] RDX: ffff9be4d13985b0 RSI: ffffffffb0d7652b RDI: ffffffffb13d4e40
[   57.150513] RBP: ffffb82601503ac0 R08: 3fffffffffffefff R09: 0000000000000000
[   57.150515] R10: bffffffffffff000 R11: 3ffffffffffff000 R12: ffff9be4d13985b0
[   57.150516] R13: ffff9be4d1098270 R14: ffff9be4e5e5c000 R15: ffff9be4d141f000
[   57.150518] FS:  00007f31cc8140c0(0000) GS:ffff9be82d53d000(0000) knlGS:0000000000000000
[   57.150520] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   57.150522] CR2: 00007f310f08d000 CR3: 0000000123806002 CR4: 00000000003706b0
[   57.150524] Call Trace:
[   57.150526]  <TASK>
[   57.150529]  ? intel_pin_eld_notify+0xa6/0xc0 [snd_hda_codec_intelhdmi]
[   57.150533]  intel_atomic_commit_tail+0x14ed/0x1b70
[   57.150540]  intel_atomic_commit+0x2bc/0x300
[   57.150543]  drm_atomic_commit+0xb1/0xe0
[   57.150547]  ? __pfx___drm_printfn_info+0x10/0x10
[   57.150552]  drm_mode_atomic_ioctl+0xb23/0xd80
[   57.150556]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   57.150559]  drm_ioctl_kernel+0xaa/0x100
[   57.150563]  drm_ioctl+0x286/0x560
[   57.150566]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[   57.150569]  ? vfs_write+0x25b/0x4e0
[   57.150572]  ? vfs_write+0x25b/0x4e0
[   57.150574]  __x64_sys_ioctl+0x4e4/0xa90
[   57.150578]  ? __f_unlock_pos+0x16/0x20
[   57.150580]  ? ksys_write+0xce/0x100
[   57.150583]  x64_sys_call+0xf1f/0x1dd0
[   57.150587]  do_syscall_64+0xbc/0x480
[   57.150591]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   57.150594] RIP: 0033:0x7f31d09cbd58
[   57.150597] Code: 00 00 48 8d 44 24 08 48 89 54 24 e0 48 89 44 24 c0 48 8d 44 24 d0 48 89 44 24 c8 b8 10 00 00 00 c7 44 24 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 07 89 d0 c3 0f 1f 40 00 48 8b 15 69 c0 0c
[   57.150599] RSP: 002b:00007fff2d980a48 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[   57.150602] RAX: ffffffffffffffda RBX: 00000000395974f0 RCX: 00007f31d09cbd58
[   57.150603] RDX: 00007fff2d980a90 RSI: 00000000c03864bc RDI: 0000000000000017
[   57.150605] RBP: 00007fff2d980a90 R08: 0000000000000002 R09: 0000000000000079
[   57.150606] R10: 00007f31d0a990f8 R11: 0000000000000246 R12: 00000000c03864bc
[   57.150608] R13: 0000000000000017 R14: 0000000037dec710 R15: 0000000000000017
[   57.150611]  </TASK>
[   57.150612] ---[ end trace 0000000000000000 ]---

so long,

Hias

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

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

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:

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

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

config DRM_XE
    ...
	help
	  Driver for Intel Xe2 series GPUs and later. Experimental support
	  for Xe series is also available.

so long,

Hias

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

Quote from vpeter

And here it is

Sorry, I wasn't aware of this thread when I implemented flatpak support

so long,

Hias

Quote from chewitt

The "throttled" message would be a thermal issue not a PSU issue. You're thinking of "undervolt" perhaps.

The throttled bits report both undervoltage and temp limit throttling, see eg [How to] Interpret RPi vcgencmd get_throttled

When it comes to USB it gets a bit more complicated:

The USB ports on RPi4 have a total 1.2A current limit (all ports combined) and if that's exceeded there'll be a voltage drop on the USB ports - but that won't show up in the throttled bits as long as the power supply can deliver the 1.2A for USB plus the power needed by RPi.

If there's a voltage drop on the USB ports pretty much anything can happen. Depending on the USB device it might lock up, go into a (temporary) error state resulting in kernel log errors or silently corrupt data on the USB HDD/SSD.

As a rule of thumb don't connect more than a single bus-powered USB HDD/SSD/DVD to the RPi, use a powered USB hub in between - and if you see odd issues connect all USB devices to the powered USB hub.

so long,

Hias