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
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.
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.
Spinning rust drives don't last forever. I see around 7-8 years from something in a 24x7x365 NAS in an air-conditioned room (the fringe benefit of living in a hot climate) and never shifts position. Variable temps and going mobile can halve the lifespan. Cross fingers and hope ..
Yes, use a manually configured IP address; don't use DHCP at all.
RPi images intentionally use an LTS kernel (currently Linux 6.18) but the rest of our codebase is now using 7.0+ which includes the reworked in-kernel NTFS drivers; and importantly the fsck.ntfs tools that allow filesystem fixing for most problems to be handled during boot, the same as EXT4. At some point the RPi kernel will bump to a newer LTS that also includes those tools, so in the long-term most of the historic challenges we've seen with NTFS should go away.
I don't see the need to complicate the GUI. If you need to override DNS just use a manually configured address.