Posts by chewitt

Add "ssh" to kernel boot params in cmdline.txt on the SD card. This forces the SSH daemon to start so you can login, stop kodi, then rename /storage/.kodi to /storage/.kodi-old and reboot. On reboot you now have a blank/clean Kodi install but can stop kodi, move important configuration items from the old install to the active one, then start kodi again to restore the previous install; except for the breaking change.

NB: This is an English language forum. If you must post in German, please also post a Google translation to English.

I pushed some testing changes to my branch: https://github.com/chewitt/LibreELEC.tv/commits/amlogic

And there's a prebuilt image here: https://chewitt.libreelec.tv/testing/LibreE…inix-u9h.img.gz

If eMMC is wiped it should boot from SD using u-boot 2025.10. If eMMC has vendor u-boot installed you'll need to configure uEnv.ini and do the usual toothpick boot method. Kernel is bumped to Linux 6.19-rc4 with no specific changes for u9h.

At least using the commits in that branch you have some scope to build > boot > fiddle with things.

I'm generally reading claims of good upstream support, although the general purpose distros saying nice things are either aiming for sponsorship from Radxa (so are likely to avoid negatives) and are typically less concerned with the small-print details of codecs and media support that good LibreELEC performance needs, so there are probably some caveats.

If what I've read is true, it probably just needs someone with hardware and intermedia buildsystem knowledge to assemble the boot and firmware packages required .. and send us a pull request.

I've no idea what the issue is, but most LibreELEC users with an RPi board are using HDMI output to a TV/AVR/Soundbar, so users with a DAC board are the minority, and as there's a broad range of DAC cards to choose from there probably aren't many folks with that specific DAC. It'll be wildly more popular among the forum audience for one of the RPi audio focussed distros.

Ahh, the lack of controls is due to the alsa conf that we are currently using. Not much I can do about that right now due to lack of time and also alsa being far from something I understand.

The analogue jack is not currently described in the NanoPi T4 device-tree. It should be possible to add, but this would need some research with schematics and vendor kernel images that I also don't have time for right now.

Share the output of route in good/bad states and connmanctl services and I have one other idea to try. Also identify the static IP of the NAS.

PrefferedTechnologies should determine which active technology has priority for the default route. If both Ethernet and WiFi have access to the internet then ethernet,wifi should result in the best connection to both internet and NAS. If only WiFi provides access to the internet wifi,ethernet will be required to ensure the default route shifts to wlan0 when the USB WiFi adapter is connected and active. If for some reason traffic to the NAS is routing over WiFi (or perhaps both) interfaces you might need to configure a static route that instructs traffic to the IP of the NAS to route over eth0. There is no way to configure that from ConnMan, but it's easily done using a system.d service, e.g. something like this (untested):

RPi5:~ # cat .config/system.d/static-route.service
[Unit]
Description=Static Route Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ip route add 192.168.2.100/32 via 192.168.2.1 dev eth0

[Install]
WantedBy=multi-user.target

Create the file then systemctl enable /storage/.config/system.d/static-route.service and systemctl start static-route and the connection will be reapplied on each boot.

No monitor/TV = no EDID data from HDMI = no alsa devices detected in Kodi = ??? but possibly something internal to Kodi depends on an audio sink being active (and in LE this defaults to alsa) for AirPlay to work. There's probably a logic bug in Kodi there, but the workaround is to run "getedid create" over SSH with the monitor attached. This captures the EDID data from the monitor and forces the kernel (and thus Kodi) to always see that monitor as connected.

I wouldn't expect it to cause issues, but it's always a possibility. Perhaps install the multimedia-tools add-on from the LE repo and then use alsamixer to reduce the output level on the master volume controls. I'm wondering if the signal is just over-driven.

Boot the board without an SD card connected. On the bottom of the resulting 'bios' like screen it will show EDID as 'OK' or none. If it shows 'OK' then I can't explain the problem. If it shows 'none' then something is not right in the chain between board and the TV; the EDID data on the HDMI connection contains info on HDMI audio capabilities so no EDID data means no audio in Kodi (hence only the BT audio pulse device shows up). TL/DR; check cables and ports and that everything is seated correctly.

I updated https://chewitt.libreelec.tv/testing/LibreE…-rock-5b.img.gz first before starting some work on an ARMv8 image that might become the future of support. We build too many images that are essentially the same aside for some compile time optimisation that doesn't make a huge different to performance. Consolidating to a single image will save a ton of CI time when building nightlies and releases.

Add video=HDMI-A-1:1920x1080M@60D to kernel boot params in extlinux.conf and see if that helps?

LE creates two partitions to run from: the first (boot) partition is 512MB and with the OS being 160-300MB in size (depending on the hardware-specific image used) that's enough. The second (storage) is more critical and needs to have 2-4GB of space for an install with media stored elsewhere (USB drive, NAS in the network etc.) or more if media is locally stored on the same drive.

So unless there's an actual problem .. "nothing to see here, move along please"

I've noticed occasional audio dropouts during movies, but there are no traces of anything in Kodi or ffmpeg logs and the event is not reproducable, e.g. rewind media and the event does not reoccur at the same point. I have no idea how to reproduce or debug this so it's something I need to flag to upstream devs. I have a hunch (based on similar issues with Amlogic hardware) that this is related to unstable clocks, but I have no way to prove that and I have low expectations of an easy find or fix.

I've not experimented much with 192KHz audio. If you have some structured test media that you can share, send me a download link; email to chewitt@ our domain or Kodi domain.

I've not seen dropped frames in videos other than some known-bad test media with exotic/problem encodings, but playback is sensitive to using correct modes so I would strongly advise everyone to use adjust-refresh and the general config outlined in this wiki article: https://wiki.libreelec.tv/configuration/4k-hdr

The kernel DRM layer is using HDMI 2.0/2.1 mode timings which are standards and both LE and Armbian are broadly using the same versions of mesa/panfrost, although this is only relevant for rendering the Kodi GUI an has nothing to do with HDMI modes and DRM connector timings. The one possible difference between LE and Armbian is that I have a bunch of in-flight patch series that enable deep-colour and HDMI 2.1 capabilities in the kernel and Armbian probably doesn't. That's all going to be merged upstream at some point though, and it's still the AVR's responsibility to generate its own OSD and overlay this onto the HDMI signal sent to the TV so if it can pass HDMI video/audio but not show its own OSD that sounds like an AVR bug. FWIW, the OSD of my 2018-ish Marantz AVR shows up fine on the rare occasions I display it.

There are lots of in-flight patch series required for the image. All current hardware decode ones are included.

I've no idea why those specific resolutions are duplicated in the selector on your system but there is presumably a difference other than the resolution that results in a different mode being listed. The display order in the GUI should be the same as the "Found resolution" data you can see in a kodi debug log (must be a debug log). You can also compare the output of "modetest" on the CLI to see what's listed there.

NB: There is no separate deinterlace section. If there are 1080@25/29.97/30 modes in the whitelist deselect them. If none of those modes are selected .. don't select them.

AFAIK the images Oleg was building are/were largely the same as official nightlies (other than nightlies now being on newer kernels and other packages). I've not heard of audio issues with current nightlies. Are you using HDMI output or the analogue port?

Quote from myrkle

Is that what you meant by "manually update"?

As nightlies can contain breaking changes we don't publish a 'releases.xml' file so neither manual update from the GUI or auto-update are possible. You need to download the update file to /storage/.update and reboot.

Papaya5595 I've updated the RK3588 images in my test share to include newer iwlwifi firmware.

Quote from myrkle

I assume this is because the build I'm using is an old alpha build and the repository doesn't support older alpha builds.

As a general rule we keep the current and current -1 repo versions for development images online, but we remove older repos to reclaim disk space. The repo version aligned to that image has probably been deleted.

You should be able to run touch /storage/.update/.nocompat and manually 'update' to a current LE13 nightly. The compat check needs to be skipped as the image name changes from ARMv8 to RK3399.