Posts by chewitt

Share the URL generated by "pastekodi" when the box is booted and connected to Ethernet. Let's see if there's a clue in the logs.

Quote from DpiTVai

Is Anyone using LibreELEC on Pi 3B with integrated chips for Wi-Fi and Bluetooth?

Approx 12,000 active installs on LE12.0 and newer (not counting nightlies) so if there was a general issue with WiFi/BT on any recent image we'd be seeing a bunch of complaint posts, and we're not. Use the RPi imager tool to create an SD card with a current RPiOS release. If WiFi and/or BT works there there's some kind of software issue with LE, but if it doesn't work the finger points towards a hardware problem. If multiple clean-installed LE releases are consistently not showing anything I suspect the latter.

It's possible something like unplanned power off (or repeated power pulls to reboot) have simply screwed the filesystems up but those issues are normally resolved with the automated fsck on boot while presence of I/O errors normally indicates a dying card. It happens and the lottery these days is normally whether the 'name' brand card you buy from e.g. Amazon is a real 'name' card or a Chinese knock-off that's so accurately reproduced that nobody can tell. RPi boards are no better/worse than any other LE device in respect to read/write "wear" on the card and LE runs the core OS from a virtual filesystem in RAM on anything with 1GB or more so it's really only Kodi related read/write to /storage that is being made. TL/DR; LE should be lighter on the SD card than conventional distros that read/write to the full medium more frequently.

The backup folder will be (by default) /storage/backup which is in the second (STORAGE) partition of the SD card which is EXT4 format and thus not visible to Windows or macOS devices that cannot understand EXT4 filesystems. You will need to copy the backup from the \\LIBREELEC\Backup SMB share or use an SFTP client to copy the file off.

Once you have a copy of the file you can try reimaging the card and restoring the backup. If it was just screwed up filesystems you should be running again quickly. If it was a dying card you should quickly find similar issues.

I would avoid attempting to clone the card as if the card is truly dying it's going to fail, and either way it's a long process. It's also unnecessary if you backed up the data on the card.

During boot the filesystem is checked and fsck is reporting a load of I/O errors. As a result some data isn't readable and a whole list of services are failing to start. The normal cause is a dying SD card. Make a backup of Kodi data that you care about if/while you still can, then (the easy fix) replace the SD card and start over, copying Kodi data back if anything was copyable.

Perhaps update one of the boxes to an LE13 nightly and see if that's more stable? (from a Kodi/functional perspective nightlies are quite stable to use, despite the theoretical alpha state).

https://www.kodinerds.net/ <= German language Kodi forum

LibreELEC is an appliance-like distro and most of the filesystem is read-only, which means there are limited places for the previous admin to squirrel away the scripts or config needed for automating things; it's all located under /storage somwhere. As there are many different ways to achieve "run this script on boot" (with the script telling Kodi to play a playlist) you'll need to dig around.

Most of what you need to figure-out/learn should be covered with articles in the Kodi wiki, e.g. https://kodi.wiki/view/Playlists and https://kodi.wiki/view/JSON-RPC_API or https://kodi.wiki/view/List_of_built-in_functions depending on the level of remote or scripted control is needed. I am not aware of any specific "kiosk" write-ups in this forum (or Kodi forum) although the question has been asked before so Google searching on Kodi + kiosk might throw up some independent results.

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?