It would be academically interesting to see the simple (but ugly) workaround in that script used on the LE install to confirm it's the same problem. If it is, the issue is deep in driver code and no amount of configurable logging will show anything useful. It would need the driver modifying to add custom debugging to figure out, and that's something for Intel engineers to do. Unfortunately they don't seem to have grasped the issue yet (admittely we didn't poke them for a while) so it remains unresolved.
Posts by chewitt
-
-
Am I going down the right track with my understanding? And what are my options?
Probably .. and since we don't need quota support (and aren't going to enable it) see https://wiki.libreelec.tv/development/build-basics for some instructions on creating your own image with more options compiled into the kernel.
-
The problem description reminds me of the issue with N100/N150 boxes where running the display at 12-bit depth (driver default) results in audio dropouts, but capping it at 10-bit results in lower HDMI bandwidth consumption which leaves sufficient bandwidth for audio to also fit. See this script: https://github.com/LibreELEC/LibreELEC.tv/pull/8588/files which remains un-merged because it's a rather ugly hack and a proper code fix needs to be found. See if that improves things?
-
Honestly no idea. We don't charge for testing though
-
johnny depp Lellek the latest Kodi package bump should have resolved the crash.
-
In LE everything runs as "root" so everything created/copied/stored on /storage is owned by root so if mounting the filesystem from the 'Live' OS you will need to have root permissions to move files there. The easiest way to do that is 'sudo -i' in the Live terminal and then use cp commands to move the files.
Or just boot the clean install and copy files to the 'backup' SMB share over the network, or enable SSH and use WinSFTP/Filezilla/etc. to move the file to /storage over the network.
-
I understand your point but I used it since yesterday with Raspberry Pi OS and everything works fine.
First you say this ^
I can see using dmesg | grep -i mmc1 that the system failed to inizialize the on-board chip.
I think it's an hardware problem for sure, thank you for helping.Then this ^
LE and RPiOS are using the same kernel source and firmwares so at the lower levels of the OS where problems with drivers and such can exist, there shouldn't be anything different between them.
Share the URL from "journalctl | paste" (or pastebin the output) please.
-
Attached: git diff official/libreelec-12.2 HEAD
Please push changes to a GitHub repo somewhere. It's easier to see/inspect what the changeset is then.
-
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.
-
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.
