Posts by chewitt

One part of the video stack has decided to render 1080p, another has decided to use a 4K mode so you're looking at 1080p rendered onto a 4K surface. I'm not sure what the root cause is, but this is occasionally reported against x86_64 and RPi hardware so it's likely a logic failure somewhere in the kernel DRM code rather than being something vendor specific.

Assuming HDMI is on the HDMI-A-1 connector, append video=HDMI-A-1:1920x1080M@60D to kernel boot params in syslinux.cfg or the equivalent EFI config (depending on which is used for boot). This will force the initial kernel DRM state to 1080@60, which will stop any attempts to use 4K modes during boot. It doesn't affect Kodi switching to 4K modes for playback.

As a general rule mesa bumps rarely cause problems, but we haven't built or tested that combination (nor are we going to) so the only way to find out is to go make the test build. The same will be true for any other packages you want to seek advice on.

Drive probe order is not guaranteed in Linux so if you insist on using the auto-generated mount names under /var/media there is nothing you can predict which device will be /dev/sda1 and /dev/sdb1. The solution is to not use auto-generated mount names and assign disklabel's to the partitions so they persistently mount under the /var/media/<disklabel> instead, e.g. e2label /dev/sda1 "Movies" will result in /dev/sda1 always mouting to /var/media/Movies. As long as you give each drive a unique disklabel there are no namespace clashes and you solve the problem.

No idea about clearing out old profile/settings/addon cruft that causes issues; trial and error is the only approach unless something obvious is logged in a debug log.

CONFIG_UNICODE is not currently set in any of our kernel configurations. Your options are:

a) Persuade a maintainer to enable support for something 99.99999% of users don't need

b) Self-build an LE image with the required kernel module enabled

c) Format the USB? drive with exFAT which is a case-preserving but case-insensitive filesystem

d) Learn better file management habits

We bumped the repo version to 12.80.6 about 3-weeks ago: https://github.com/LibreELEC/LibreELEC.tv/pull/11036 so it makes no sense that a nightly image from 3-days/nights ago would still be looking for the 12.80.5 repo (which no longer exists).

Two suggestions (in sequence):

a) Update to the latest nightly image.

b) Stop Kodi, rename /storage/.kodi to /storage/.kodi-old, restart Kodi. This gives you a clean install .. do you still see the same behaviour? If no, stop and copy back bits of config that you need, and continue to use the newer instance. If yes, put Kodi in debug mode and then run "pastekodi" after rebooting and share the URL.

As long as the JSON-RPC interface has been enabled in Kodi settings (something like: allow access from other systems) there is no functional difference between Kodi on LE and Kodi on other platforms.

Also check for thermal issues. If the SoC gets too hot it will self-throttle resulting in reduced performance. These boards are happy running at much hotter temps than we're comfortable with but there are limits. Software issues that stuck/spin CPU cores can get things hot though and RPi4 requires notably more cooling than RPi3/RPi5.

The kernel change between LE12/12.2/13 is significant on pretty much all platforms except for RPi, as RPi is the most code-complete codebase and there's no new hardware. Generic needs the bumps to support hardware. All other ARM SoC platforms need them to add features and capabilities.

If you look at the timestamps in the log and correlated to download failures, they start on 23/03/2026, then time jumps forward to 03/04/2026 after the network comes up and NTP updates the clock. So you need to enable 'wait for network' in LE settings. That will reduce the initial set of http(s) failures and might also allow add-ons to update correctly. You can also force-refresh the repo to make Kodi try again. The 12.80.5 repo has been deleted now as we bumped the version to 12.80.6 some time back, and IA is here https://addons.libreelec.tv/12.80.6/ARMv8/…tream.adaptive/.

NB: Use the built in 'paste' function in future please, downloading logs from the forum is a chore.

You can enable persistent logging in the LE settings add-on (requires reboot after) and this will allow you to reboot and then share the previous system log with e.g. journalctl -b1 --no-pager | paste but if the Kodi process simply goes unresponsive instead of actually crashing (which will leave traces) there's probably still nothing to see. You can also look at kodi.old.log (boot -1) to see if there are signs of problems there too. Kodi will also record crash logs, but (again) that requires process termination to happen and other problems like resource starvation won't necessarily effect a crash.

You can also update to a current nightly to see if that magically fixes anything. Backup /storage/.kodi to /storage/.kodi-old first to make downgrading possible.

The perf stuff is harmless, just the kernel managing itself.

I've been doing some general work on decoding robustness with Claude to reduce some of the errors that show up, but then got distracted with trying to make mpeg2 work (not there yet) and need to either finish (or more likely abandon) that and then reinstate HEVC support into the kernel tree I'm using before pushing things into images. I wouldn't expect a great leap forwards though; decoding is waiting on Amlogic managing to upstream stateless support (S4) and then we can maybe start to expand the hardware supported and backfill older hardware generations. Until then you need to ensure you're following the general recommendations in https://wiki.libreelec.tv/configuration/4k-hdr as using whitelists etc. is really needed to get the best (or least worst) result from current decoders. And you should not expect the same level of performance as the old vendor kernel, which is shockingly horrible code, but more functional. NB: debug logs are not going to be insightful so you can save you/me the effort.

Quote from kapqa

Hello , is it possible to receive LibreELec 9 or 10 for devices with RK3568, RK3566 with armhf or is this unrealistic?

It's all open-source so you're welcome to go experiment yourself, but subzero interest from me.

Anything running CE is not our problem. Anyone failing to use their forum is not our problem too.

Quote from SoloUnRandom

I tried putting the Armbian driver on /lib/firmware because i thought that would work (SPOILER: it didnt)

Drivers are not firmware and need to be added to different locations. You cannot overlay drivers without compiling a custom image to add the function to do that, but then you might as well just compile the driver normally.

LE has no support for the Odroid C5 board so you must be running an Armbian or CE image; thus you are in the wrong forum. We have no interest in and do not support the codebase you are using.

Use the AMLGX "box" image and then map/configure your own remote. Go read:

https://wiki.libreelec.tv/hardware/amlogic

https://wiki.libreelec.tv/configuration/ir-remotes#configuration-advanced

You can enable persistent logging in the LE settings add-on. Then you can do journalctl -b 1 | paste to pastebin the previous system log (current boot = 0, previous = 1, etc.). I'd be looking for Out Of Memory (OOM) issues and other kernel splats in the log.