Use an LE12 nightly. Put Kodi in debug mode. Reboot. SSH in and run "pastekodi" and share the URL generated.
Older NUCs only support CEC wake; hence the other options are missing. It does HEVC/H264 so should be generally useable, though not sure about VP9. Adding CEC can be done with the Pulse8 adapter if they still exist or can be found at a reasonable price. I'd also look at learning remotes that replace the stock TV remote (nb: these days most TV remotes can learn too).
LE support for Rockchip hardware is mostly aimed at SBC boards. There is an image for a "Hugsun X99 box" but I wouldn't assume that anything found on Aliexpress is 100% the same (there are lots of clones) so it might work, or it might not. Rockchip support mostly depends on upstream activity too. RPi5 is lacking native emmc (although add-on HATs are appearing for that now) and VP9 but is the gold standard for LE software support, and it seems to handle 4K/VP9 up-to 30fps (not 59.94) in software fine. At the current time 4K GUI is not recommended on ARM boards (and most Intel H/W) even the HDMI output is technically capable as all Kodi skins are 1080p and the TV almost always does a better job of upscaling 1080p to 4K than Kodi does (Kodi needs to do it in software and this will noticeably slow down the GUI. CE probably has options but their approach to open-source software seems to involve not-always providing sources and deliberately using pre-compiled blobs; most users don't care, some find that distasteful and look for something else. I don't run it so cannot recommend it.
If the 4K/UHD rips you make are HEVC then the RPi4 should handle them fine, and is free since you already have it. RPi5 is faster in GUI nav and a few other things but that's spending $$. I haven't used Intel hardware in years so can't make a recommendation on that side (RPi5 is the daily-driver).
What is now the next step for this issue?
Will your fix get merged into the main libreelec repo? Or will people with newer intel cpus be dependent on your fork?
It's a workaround not a fix, so further investigation is needed to identify and resolve the root cause. Links to the Intel DRM issue tracker were posted already. The Intel devs that you need to contact are probably lurking in the #alsa-dev IRC channel on Libera and/or the #linux-media channel on OFTC too; but start with formally recording the issue on the tracker.
What happens if you complete the Wizard in English, then reboot, then change Kodi to German language after reboot?
Cron normally requires the full path to a binary, so "/usr/bin/dd" instead of plain "dd" but the rest should work. You might want to log output to somewhere on /storage to ensure it works fine.
Check to see that Kodi addons ‘service.tvheadend42’ and ‘pvr.hts’ are installed and enabled
Just be advised that the moment there's upstream movement on a TVH 4.4 release we will be dropping the TVH 4.2 add-on (as 4.2 will no longer be the 'stable' TVH release). It would be better to develop against the 4.3 add-on.
SD card issues appear to be resolved, but I haven't pushed the changes to the main LE repo yet; hence not in nightlies. I'm using a newer kernel than the rest of LE and some breakage in shitty Realtek drivers need to be resolved before I can push the Linux 6.7.0 kernel bump to the main repo. NB: We don't need "testers" we need people that write kernel drivers 
The settings add-on provides a backup/restore function not a backup/migrate function so "everything is working as expected" from our perspective. You need to clean install on the RPi5 then copy the .tar file to the device, unpack it, stop Kodi, then selectively move the bits you care about to their required locations and restart. You may find that you need to create/setup a passwords.xml file to go with sources.xml if you updated from a much older release. Otherwise things should work. In library views the /path/to/file detail is only shown under the "refresh" icon.
Any ideas?
Don't change the NAS name in the first place?
There are lots of different software RAID options. If we add one type for one (small) group of users we'll have to add more types to appease all the other (small) user groups that want something different. Then if we add 'only' the kernel options users will whinge about not having all the userspace tools that are needed to safely use and manage all the different RAID types and use-cases that come with the topic. This compounds the opportunity for complex support issues and increases the software maintenance burden and image bloat (the death of a thousand cuts) for the distro; so the project has always (since early OE days) resisted adding RAID support. Fortunately the distro is open-source with an excellent and simple build-system, and you are welcome to modify it as you like.
This patch is needed to revert a change that causes glitchy playback and other issues on several platforms https://github.com/chewitt/LibreE…rt-fences.patch
I'm waiting for RPi devs to figure out something with deinterlaced support, then I'll push that patch, a kernel bump to Linux 6.7.0 and few other changes up to the master branch. I forget whether the files currently in my test share have that fix included, or also include something that stops deinterlaced media playback from working .. you're welcome to experiment:
It's more time-consuming than complicated. Start with building an Ubuntu 22.04 VM and getting an initial image built.
Two suggestions:
Test again with an LE12 nightly image to see if the issue exists with Kodi 21 (Omega). I'm not expecting there to be a major change between K20 and K21, but it's important to know as development is now focussed on K21 (and will soon shift to K22).
If the issue does exist in K21 it needs to be reported to Kodi developers via the Kodi forum as changes to the DLNA code are not something that LE devs have created; all we do is bundle upstream Kodi into a convenient distro image.
H3N7R1K If you expected this experimental and developed-for-free (nobody charged you money) image to do anything more than boot (which might be pushing it on some hardware) you have rather inapropriate expectations. As the tone and language of your post were also not appropriate for the forum, it has been deleted.
The sequence would be: Stop container > Restart Docker > Start container .. not just restart Container or Docker. No ideas if that's the issue but I've seen similar things in the past (and admins restarting things in the wrong sequence resulting in no change).
