The only thing that comes to mind is SMB versions? .. i.e. old NAS was configured for SMBv1 which requires the Kodi SMB client on the RPi to be configured for min/max SMBv1 (else it connects at SMBv2 and cannot downgrade the connection to SMBv1) and new NAS has defaulted to SMBv2/3 thus prevening the Kodi SMB client trying to use min/max SMBv1 from being able to connect.
If that's not the right blind guess, as a minimum you'll need to divulge what protocol is used by Kodi.
Fcast reminded me of https://xkcd.com/927/ 
Use the wireguard systemd service as a template for something that runs after the network is up and before Kodi starts; change the systemctl command for whatever commands you need to mount the array. Add more ExecStart= lines as you need to run the commands in sequence. If you need more logic and error handling put the commands in a script in /storage/.config and then run the script from the systemd service.
I'd guess that's the performance issue that the pmdomain patch (we dropped) referred to. Was it enough to just add the right kernel options for the regulators to get things booting again or was the patch revert essential?
Casting features need to be implemented within Kodi not the underlying OS (LibreELEC)
rkman Saying "black screen" and then "rendering works fine" sounds contradictory so I'm guessing the Kodi home screen shows up eventually? so the screen is only blank during early boot?. If yes, this is prob. due to the kernel now supporting 4K output and in early boot a 4K mode the TV doesn't quite agree with is used. The workaround is to append video=HDMI-A-1:1920x1080M@60D to the kernel boot params in extlinux.conf so initial output is forced to 1080p instead. As a general rule you want to run Kodi at 1080p and only switch to 4K for playback anyway (see https://wiki.libreelec.tv/configuration/4k-hdr).
NB: If the board is booting from downstream Rockchip u-boot on SPI flash you can probably expect random behaviours. It's best to wipe SPI and allow mainline u-boot (2025.10) on the SD card or eMMC module (wherever LE is flashed) to be used instead.
ffmpeg 7.0 was updated to 8.0; the add-on repo version was already bumped and add-ons are already being built. The mpd add-on should update itself in the next 24h.
The existing config worked fine at one point but systemd is a continually evolving beast so perhaps something was improved and now needs additional config juju for things to work as before. If something needs fixing .. send a PR with a decent explanation of what is being changed and why, and it will be tested (over a range of build targets) and if good, merged.
Moved to off-topic as this has nothing to do with LibreELEC support.
orclex I've picked the details into one of my branches, it will be merged next time I push some changes to our main repo.
The contents of /storage/.config/system.d are overlaid onto the virtual filesystem after SYSTEM is expanded on boot, so if you want to change config of an embedded .service file just clone the file to that location, make edits, and reboot. The same is true for other special folders under /storage/.config/ .. or you need to start building custom images with your preferred changes baked-in during compile via the buildsystem. The former is fine for quick tweaks and tests. The latter will be easier to sustain over a longer period.
Donations to project funds are always welcome but if there's even a hint of an expectation of a donation buying special treatment or custom images; keep your wallet closed to avoid disappointment.
I'm wondering if the elfarto VAAPI shim works better: https://github.com/elFarto/nvidia-vaapi-driver/
NB: Our general advice since 2016 is to avoid the purchase of nVidia hardware for LE use due to distro packaging for nVidia support being a clusterfcuk. The nature of the clusterfcuk has changed a few times over the years, but with each improvement nVidia never fails to add some new complication that keeps the status quo intact.
If the OS is running but no graphics (and thus no Kodi) I'll make an educated guess the problem is mesa related. See if reverting to the mesa version used with the last known working images restores things? If yes, you can manually bisect between known-good and known-bad mesa versions to find when the breaking version change occurs; then you can look at mesa changelogs/commits to see what commits might be involved.
NB: I'm guessing mesa because the panfrost kernel driver has received little real-world change over time since it was added, but on the userspace side mesa has a high rate of change and mesa automated testing will be done against Bifrost hardware, and perhaps the second generation Midgard T860 used in some Chromebook devices; not the first generation Midgard T628 used with XU4 which has an inconvenient amount of silicon "errata" that often require complex or fugly workarounds.
The Lakka folks had images with Mali blobs in the past and I have fuzzy recall of there being some older LE community images from zalaare but our official releases always used upstream kernels and mesa/panfrost.
If you’re lucky it’s missing firmware. If you’re unlucky it’s the older Broadcom driver that we dropped. Share the URLs generated by “dmesg | paste” and “lspci | paste” and we should be able to see.
The first official XU4 image was LE11 (10.95.1 = LE11 beta1) so there is no 9.2 image and CrapGPT is halucinating answers. The last time I dug one out for testing was about 12-months ago and at that time Audio/Video were working fine; albeit XU4 is showing its age and only supports H264 hardware decode. NB: The main reason we still have it in our board line-up (and also the main reason we added support back in 2020) was so that Lakka can use it for retro-gaming.
