Posts by HiassofT

We use kodi upstream sources with a couple of patches applied on top, the common patches are in https://github.com/LibreELEC/Libr…er/kodi/patches and the RPi specific ones are in https://github.com/LibreELEC/Libr…Pi/patches/kodi

Kodi version/githash and cmake/configure options are in the package.mk file https://github.com/LibreELEC/Libr…kodi/package.mk

Our RPi ffmpeg patches are in https://github.com/LibreELEC/Libr…g-001-rpi.patch and are sourced from jc's ffmpeg tree (the same that's used for RPiOS), the commit message of the patch file will tell you the exact version used, currently that's https://github.com/jc-kynesim/rpi…4d573df97223cd9 from the test/8.0.1/main branch - might be easiest for you to use ffmpeg sources directly from there.

Also see the package.mk for configure options https://github.com/LibreELEC/Libr…mpeg/package.mk

so long,

Hias

The instructions in the wiki are outdated and wrong, /usr/lib/firmware should be added to the cpio, not /lib/firmware (the latter breaks the lib->usr/lib symlink and then everything goes south).

Just use the "create-edid-cpio" script which is included in the image, it'll create a working /flash/edid.cpio with all files from /storage/.config/firmware/edid

so long,

Hias

Looks like you added vc4.force_hotplug... as a second line - this doesn't work, everything in cmdline.txt needs to be in a single line.

Move that up right after console=tty0, separated with a space, and try again.

so long,

Hias

Are you running Generic-Legacy?

If yes I strongly recommend you resize the 512MB boot partition to 1GB or create a backup, do a fresh install and restore the backup. 1GB is the default for Generic in LE12.2 and newer.

The Generic-Legacy image got really fat, mainly due to the Nvidia driver which is huge, and likely you'll soon run into issues on updates.

so long,

Hias

Update to LE12.2.1 (best do a fresh install on a separate SD card), LE10 and Kodi Matrix are long end-of-life. If the issue persists please post a full debug log using "pastekodi" via ssh or the log upload function in LE settings.

Thanks for reporting back, glad to hear it's working now!

I've PR'ed the changes for LE13 and LE12.2. It will take a while until it's in nightlies so in the meantime here's a LE12.2 image - would be nice if you could confirm if that's working, too:
https://www.horus.com/~hias/tmp/libreelec/LibreELEC-RPi5.aarch64-12.2-devel-20251214204956-b7754e4.img.gz

so long,

Hias

Please first update the bootloader (in LE12.2.1 go to Settings->LibreELEC->Update, scroll down to the end) and then test with a fresh installation of this image (leave config.txt alone for now):
https://www.horus.com/~hias/tmp/libreelec/LibreELEC-RPi5.aarch64-13.0-devel-20251214122221-2bad22a.img.gz

SATA support isn't enabled in our RPi images ATM, the above image adds that.

If it doesn't work please again post a 'pastekodi' log.

so long,

Hias

Please update to LE 12.2.1 and provide a full log if it doesn't work

so long,

Hias

We just added a fix for this issue, see https://github.com/LibreELEC/LibreELEC.tv/pull/10785, images are currently building and will be available in about 12-24h.

If you use an RPi5 please note that you need to update your bootloader before updating to current nightlies - see Important: LibreELEC 13 on RPi5 requires bootloader EEPROM 2025-02-12 or newer

so long,

Hias

With the update to kernel 6.18 RPi5 requires bootloader EEPROM 2025-02-12 or newer to be installed, otherwise LE won't work properly (eg you won't get any output on the screen).

Make sure your EEPROM is at this version, or newer, before updating to LE 13 builds after 2025-12-10:

If you are running LE12.2 or LE13 go to Settings->LibreELEC->Update, check Bootloader EEPROM update option at the end and install the update if needed.

Older LE versions don't ship with new enough bootloader EEPROM updates, if you want to update to LE13 either update to LE12.2 first or use a spare SD card and the Raspberry Pi Imager to create a bootloader recovery card and boot from that:

Download Raspberry Pi Imager from https://www.raspberrypi.com/software/ and install it, then choose device Raspberry Pi 5 and OS Misc Utilities->Bootloader->SD or NVME/USB or network boot (depending on your setup). Boot the RPi5 from this rescue SD card, after a few seconds you should get a green screen which means "success".

Audio is a bit tricky.

It's best to leave the EDID of the second HDMI port as is (using "getedid create" to fetch and force the EDID read from the AVR etc is fine), so it's using the info from the connected AVR/audio extractor/... - it you use some display mode not supported by the AVR, force some speaker allocation that doesn't match what's connected to the AVR etc things will go south.

For the EDIDs used by the first HDMI port / monitor it's best to create 3 different ones for 2.0, 5.1 and 7.1 setups (this is eg also what my HDFury VRROM offers in it's built-in EDIDs).

Enabling higher sample rates than 48kHz or compressed formats like AC3, DTS, MLP etc shouldn't hurt but keep in mind that there are audio bandwith limitations on the lower res modes. 720p50 and above will do 192kHz 8ch fine, but modes below are quite limited (eg 640x480p60 only allows up to 8ch 48kHz or 2ch 192kHz) - IIRC there's some info about that in HDMI or CEA specs.

If you use some HDMI audio extractor or similar (or even just a TV/monitor with audio capability) you'll also have to test if it actually works with the custom modes you added - some may only work fine with the standard HDMI modes but not with anything else.

so long,

Hias

There isn't really anything we can do here.

Modifying EDIDs would be something that needs to be done deep down in the linux kernel and that has a high risk of breaking things - just look at the cheap chinese HDMI audio splitters which modify EDID on the fly and break stuff because they didn't get it 100% right.

Also adding modes that are not supported by a monitor may at best confuse users (I did a test with your EDID and my monitor didn't like 1440 × 1080 and 640 × 480 96Hz modes - signal out of range) or even worse interfere with kodi's whitelist because it may pick one of the additional modes instead of the actually supported modes reported by the display.

The way forward is that you create a curated, known working set of EDIDs that pepole can choose from - similar to what HDFury is doing, see eg https://hdfury.com/tools/HDfury_EDID_collection.zip

People can then pick one of those EDIDs that match their setup (eg either 1440x1080 or 640 × 480 96Hz), verify on their own that it really works with their display device and use one of the standard methods to inject it - either the edid override you get "for free" with linux, with an external "EDID fixer" device like the HDFury Dr.HDMI, VRROOM or similar ones, or by patching/reprogramming the HDMI sink (the latter would risky and often might not be possible to do though).

so long,

Hias

sinbad74 That's expected. since you have the Digi 2 Pro you also need the digi-pro dtoverlay, not the digi one (which is for the older, non-pro card)

so long,

Hias

For some reason the ext4 / storage partition has a different UUID.

Adjust the disk=UUID=783... option in cmdline.txt so it matches the actual UUID (disk=UUID=0cb...)

so long,

Hias

Drop all workarounds you added so far, it should simply work out-of-the-box with the new image.

so long,

Hias

I've managed to identify the culprit, it was iptables: https://github.com/LibreELEC/LibreELEC.tv/pull/10757

The fix will be included in the next nightly image.

so long,

Hias

You can't have kodi output on both HDMI connectors. The best thing you can do is to force output to a specific HDMI port via advancedsettings.xml and then restart kodi. See RE: [RPi4] HDMI Audio with Touchscreen

so long,

Hias

It's best to stay away from the MCE keyboard protocol, it's a bit of a mess and as you noticed it doesn't work well.

Reprogram your Logitech remote to use the standard RC6 MCE (remote) protocol and it should work fine out of the box.

so long,

Hias