Thanks for testing and confirming it's the same issue. I'll revist the bug report with Intel devs to inform that their latest fancy card suffers the same fate as a cheap N100 box. I can't guarantee it will stimulate action, but nothing to lose.
EDIT: comment added to https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10199
Bring up the OSD .. click on the (i) button and remove (i)nfo from the screen. Or press 'i' from a connected USB keyboard. Or press 'i' when using the kodi-remote virtual remote over SSH.
I'll try to go through the link you sent me in detail soon. If I have some questions, would it be OK to ask you back here in this thread?
Sure. In high-level detail: Create a default image first, then all you need to do is modify the kernel defconfig enabling the missing kernel options then re-run the same build command. The buildsystem will run through the image build process again but only rebuild the kernel package. Once complete, push the image .tar or .img.gz file to /storage/.update and reboot to update using the custom image.
The config here is generally recommended https://wiki.libreelec.tv/configuration/4k-hdr and is written by me from experience with multiple ARM SoC boards; but mostly RPi4 and now RPi5 which are the family daily-driver devices. I don't have any issues with green artefacts on the screen aside from occasional moments streaming live broadcasts from a Tvheadend instance; due to signal issues on the DVB-S2 side of the setup, or bandwidth glitches which result from the Kodi client being 7,000Km from the server.
I would start with an update to a current LE13 nightly as even if you find an issue with LE12/12.2 we have no plans for more releases that would bring fixes to that version. Running newer/latest everything might not solve anything; but at least you eliminated 1,000+ differences between versions from possible suspicion.
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.
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
