Zero 3W, and it booted fine however, no wifi card appears to be detected, nor bluetooth
I can see that device-tree defines the module, but I can't see anything in documentation that states which Broadcom chipset is being used. It's probably something new(er) that we don't have firmware for, but as you didn't share the system log .. that's only a blind guess and could be wrong. In short .. no idea 
axel I forget exactly what the issue is, but IOMMU errors are seen with RAM sizes over 4GB so LE currently and intentionally sets mem=3838M in kernel boot params to sidestep the problem. You are free to remove that param and see the full 8GB, but expect other issues. NB: LE runs in under 1GB so it has zero functional impact on Kodi use.
You can refer to https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
Most of the staff and forum regulars around here (self included) don't bother looking any further into a log the moment they see them installed.
Will there be an update from 21.2 to 21.3?
If Kodi release a 21.3 version we will push another LE update to include it.
NB: Kodi have no current plan for one. The focus really needs to be on getting K22 shipped.
SSH in to the box, make /flash writeable with mount -o remount,rw /flash then append video=HDMI-A-1:1360x720M@60D to kernel boot params in syslinux.cfg in the boot partition and it will force the initial kernel DRM state for the HDMI-A-1 connector to use that mode. For this to work the kernel needs to detect/see that mode via EDID data on the same connector. Adjust the connector name to match whatever HDMI port is being used (if there is more than one). Adjust the resolution to one that is listed if not, e.g. if the TV supports 1080p then use 1920x1080 not 1360x720. The kernel is probably auto-selecting an initial display mode based on the modes advertised but for some reason the TV doesn't actually like that mode (bad EDID data can be a thing sometimes). The same is seen sometimes with 4K TV's and forcing the initial state to 1080p helps.
Always post the solution!
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.
