Posts by chewitt

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.

How you configure something is about how to use the app, not how we packaged the app into an add-on.

I'd suggest to ask the question in https://tvheadend.org

taki Thanks for sharing the patches, they are interesting reading! .. once decrypted from Turkish to English

Some of the comments you've made are valuable. I was seeing an attach issue with MxL608 behind an AVL6762 i2c repeater when working on my O2.cz box, and while trial and error with Claude eventually figured out a "fix" and theorised an explanation, one of your comments explains the actual problem and better/correct solution.

Quote from Viking1

lt's been a very long time since a nightly build, version 12.2, for RPI5! How come?

There are no further Kodi 21 releases planned, and no further LE12.2 releases planned, so unless there's a random bump to some package (last one I can see was tz-data on 3rd March) nothing changes and there's no reason to build nightlies. There have been some bumps to add-on packages, but those are built/handled separately.