Only for information about HW from Linux version 6.19.0
To be crystal clear, I have zero interest in bug reports against this kernel as it's about to be superseded with the 7.2 kernel as used in the images from my test shares. Dealing with temp things is a low priority to investigate, so repeatedly posting the same "still not working" post is just becoming annoying. I also haven't read the AI-slop 'guidance' posted, because Gemini is total garbage.
It's not changed since OpenELEC days and is still supported:
This will get merged later and should be in nightlies within 24-48h: https://github.com/LibreELEC/LibreELEC.tv/pull/11711
Some analysis of Kodi and libnfs by Claude suggested https://github.com/sahlberg/libnf…d476e423ae0fff9 added between 6.0.2 and 7.0.0 causes the problem, and is solved in https://github.com/sahlberg/libnf…8e88ea7e15c3229 which has been merged since 7.0.0 that we bumped to; so please test https://chewitt.libreelec.tv/testing/LibreE…-12.95.1.img.gz which bumps libnfs to the current latest commit to include that, and report back.
On my Synology NAS the max. NFS protocol is set to NFSv4.1 and it‘s not working after the libnfs update.
Is the Kodi NFS client configured for NFSv4? - the default is NFSv3
https://chewitt.libreelec.tv/testing/.Libre…-12.95.1.img.gz is a current LE13 nightly (ignore the odd version) with the recent libnfs bump reverted. Test and report back.
That sounds like an insufficient response/timeout value in the DRM code somewhere. I'd look, but i915/xe have a bazillion lines of code so it would be needle-in-haystack for my ignorant eyeballs. If you have time/access (and importantly, the hardware) perhaps ask an AI tools to look for it?
I'm probably missing some context. What problem is the Denon resync script solving?
set it off in modem/router and modify /etc/resolv.conf
ConnMan 'owns' /etc/resolv.conf and will rewrite the file under certain operations; thus erasing changes.
I wasn't aware that change was merged. We probably need to patch it out of the GUI to avoid people saying the monitor selector doesn't work; because Kodi GBM does not currently support dynamic change of the DRM connector used for output.
If you want something efficient that just works and doesn't have the issues: use Estuary. If you want eye-candy and a slower GUI experience and issues: install other skins. I'm probably being mean to some skinner who slaves thousands of hours on their skin project, but 15+ years of Kodi (orig. XBMC) use has taught me that lesson 
So, Wireguard can be set as a server in LibreElec and I do not need containers? Or I script in a container? Any pointers to reading material or how to start?
As WireGuard operates at Layer2 and Layer3, there is no higher (Layer) server component/application involved. It is nothing more than a network interface configured from userspace using the wg binary and a config file. The config file contains the public/private keys for communications and configured knowledge of other peer nodes in the mesh network. Once the WireGuard interface is up you can route traffic to/from the interface using normal ip commands. The config file may also have other information used by the wg-quick script (referenced in most HOWTO guides) to create the interface and set routing. LE does not bundle wg-quick as it does not work; it assumes a standard Linux desktop and fails with our read-only OS packaging. However, all wg-quick does is dump some files in /etc/wireguard then run wg and ip commands. If want to know more about it, find a copy on the internet.
In all seriousness, I would start here: https://lmgtfy.com/?q=how+does+wireguard+work%3F - because WireGuard is more like IPSeC than OpenVPN and if you do not understand how it works you will flail around looking for an 'easy' button that doesn't exist (as it is not required). Everything needed is embedded in the OS and /storage is your persistent writeable $home folder, and you can use all the standard Linux tools like systemd services to start things on boot. You can also install containers; but that only adds overhead and the abstraction of containers (most users don't understand those either).
WireGuard is WireGuard and all ConnMan does is start the daemon with the config that you create. Nodes can be both client and server and since WireGuard is part of the kernel you don’t have to use ConnMan and can just script things as you need; and you can disable the ConnMan VPN service if that gets in the way. Adding containers to run binaries that already exist in the host OS is just adding overhead and complication to the process. Stop using dumb AI tools and learn how WireGuard works; it will save you time in the end.
The updated RK3288/RK3328/RK3399 images in my test share workaround a DRM plane selection problem in Kodi on RK3399 and an issue with the IEP(1) hardware deinterlace driver that prevented it from working (on all three chips).
LE13 includes a kernel patch that caps the Intel GPU driver to 10-bit output which is another way of achieving the same functional limitation as the sky42 script; although the script also effects a reset of the DRM connector and that might be a workaround for other problems.
Using the Beelink N150 box that I acquired for testing; without the patch I hear audio dropouts in most 4K HDR (and HBR audio) media, and with the patch I don't hear dropouts. I've not had issues with no-audio after playback end. I've also not seen any issues with blank screens after playback. I sometimes see blank screens during early stage boot but that's on multiple hardware platforms and I think nothing more than fast booting and slow (enough) HDMI handshaking with the AVR.
It would be interesting to see a clean pastekodi log (with Kodi in debug mode) that demonstrates the audio and/or video dropout after playback end.
I was originally asking because I hit an issue with https://github.com/xbmc/xbmc/pull/29006 and (misreading the post on a phone) wondered if it was the same thing occurring - despite the 'Fix SMB' title the issue is a general networking issue and has nothing to do with SMB. Having re-read the description in a normal browser you're accessing the share in some form so the issue must be something different.
NB: You can enable persistent debug logging in the settings add-on, then e.g. journalctl -b 1 --no-pager on the CLI should show the previous boot.
The LE settings add-on has long history of "if it works, don't fix it" style maintenance because it's all Python code that nobody on current project staff understands; and in that context you'll argue "but it doesn't work" and I'd argue it does for 99.9999% of our users and Dr. Spock's logic quote "the needs of the many outweigh the needs of the few" applies. There's also a general desire to keep interfaces simple and supporting all possible configuration options generally adds complication.
That said, the codebase is all GPLv2 and open-source so there is nothing to stop someone submitting the technical changes that implement the feature you desire. It's just unlikely to be someone on staff as we have learned to avoid that Python juju.
[ 125.938972] rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
This ^ is completely harmless. Ignore.
