Posts by chewitt

We aren't going to touch LE12/12.2 images again as development shifted to LE13 aeons ago. So the first thing to do is retest with a current LE13 nightly. If the issue is resolved, great. If the issue remains, you need to share proper technical details on the problem, i.e. debug logs from Kodi and/or Tvheadend that reveal what the possibly-changed magic stream format is. Until then the not-good answer to your not-good question is "Yes, shitloads changed in ffmpeg between releases" because the ffmpeg major version has been bumped and ffmpeg is a rather busy active codebase. Kodi is tightly integrated with libavcodec (not the static 'ffmpeg' binary from the tools add-on) so even if you did self-compile an LE image with an older ffmpeg version inside you're likely to cause other breakage. I'm 100% confident the unknown problem has nothing to do with an arm vs. aarch64 change.

The memory cap has been removed in RK images for a while now but we don't parse exlinux.conf during updates so if you installed with the cap it will be there until you remove it.

Your guess is as good as mine on HDMI 2.1, but with the HDMI association veto'ing AMD's implementation I doubt developers will spend time on it due to the high probability of rejection and/or being sued. Was there a specific capability you were looking for?

Up to you ..

Quote from ServeMe

Hey chewitt, I think I've seen you somewhere else lately...

I have my fingers in a few pies

I'm suggesting to experiment with LE running on bare-metal from a USB stick because I'm not interested in troubleshooting VM problems unless the hardware actually works in our distro. If you continue with LE, you can run commands via SSH, either over SSH from a console, or in a web browser if you install the TTY service addon from the LE addon repo.

If you want to experiment with Tvheadend on other distos that's also fine, but out of scope for this forum.

I'll state the obvious first: we don't officially provide any support for running LE in virtual environments. The Generic OVA exists to support occasional GUI oriented dev work; e.g. at the recent Kodi DevCon (in Spain) I've developed a Tailscale add-on by using the OVA running on an ESXi box at home (6,000km away). If users want to experiment with LE in a VM for other purposes that's fine, but there should be no expectations of support or interest (or timely bugfixes) from staff.

So, with the disclaimer done:

I would experiment with LE on a USB stick first, to prove the DVB hardware is supported, has the right firmware etc., and runs well, before add a layer of obfuscation attempting the same thing in a VM.

Google says AF9015 is a combo chip that contains a USB bridge and AF9013 demod, so Tvheadend showing an AF9013 demod is probably correct; it wouldn't care about the USB bridge.

If things are not working when running LE from a USB stick, run "journalctl | paste" and share the URL so someone who knows more about DVB things can comment.

The addon repo version was bumped from 12.80.5 to 12.80.6 about a month ago and the .5 version no longer exists (hence the error). As noted above, I'll get an updated image out sometime this week.

Using the AMLGX image "emmctool" has a backup function which is just a raw dd copy of /dev/mmcblk1. The boot0/1 devices aren't used for anything as u-boot is on the main block device so those should be all zeros, but I guess no harm to have them too.

I've been poking some interesting Amlogic things over the last week and Kodi DevCon + travelling was the weekend before. I'll circle back around on Rockchip things in the next week. You're not missing anything essential.

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.