The online repo the .tar.xz file is downloaded from has (for unknown reasons) regenerated the download and this has caused the hash of the downloaded file to change. We see the same on GitHub sometimes.
The correct fix is updating PKG_SHA256 in package.mk to use the 'got' hash value instead of the current 'wanted' hash. The alternate workaround is setting PKG_SHA256="" (null) which disables the hash check. The one-line command vpeter posted does this.
https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-v1.0.20250521.tar.xzThis URL ^ (correctly formatted, unlike the one you posted) works fine for me.
Or bump bump the wireguard-tools package to the current release, e.g. https://github.com/LibreELEC/Libr…ools/package.mk
Or download the .tar.xz file from somewhere else (and storing it with the correct filename) to sources/wireguard-tools/ and then manually generate the required .url and .sha256 files and content (look at existing files to crib the simple format).
Doesn't the kernel detect devices at boot time?
It should, but the user has provided zero evidence that it did, and they've also been fiddling with files they shouldn't. So the normal protocol is to ask for evidence (the LE13 pastekodi output, which will show the full EDID block, full log, and system log) so that blind guessing isn't involved.
cp /usr/lib/udev/rules.d/95-udevil-mount.rules /storage/.config/udev.rules.dClone the udev rules file ^
# check for blockdevices, /dev/sd*, /dev/sr*, /dev/mmc*, and /dev/nvme*
SUBSYSTEM!="block", KERNEL!="sd*|sr*|mmc*|nvme*", GOTO="exit" <= edit this
# check for blockdevices, /dev/sd*, /dev/sr*, /dev/mmc*, and /dev/nvme*
SUBSYSTEM!="block", KERNEL!="sd*|sr*|nvme*", GOTO="exit" <= to this, i.e. drop mmc*Then edit the file using nano and change this block towards the top of the file ^ then save/reboot to effect the change.
The change means for any mmc* blockdevice it skips straight to exit and doesn't process partition mounting. NB: This will also prevent SD cards from ever mounting as those are also mmc* devices. I doubt you need that though.
There must be an audio routing error on LE side.
Are you using tea leaves or a crystal ball to derive this knowledge?
Using an LE13 nightly image (as 12.2 will not contain the info I'm looking for) do a clean install, put Kodi in debug mode, reboot, then run "pastekodi" and share the URL so we can see the log.
The Kodi release process has been a little challenging over the last year. This is partly due to different people picking up a complex an unpopular task, but also because there's a desire to release for all platforms at the same time and we've repeatedly seen issues with one platform which takes days-to-weeks to resolve. In the meantime development continues to roll forwards and more things get merged into the master branch: hence the staggered timing between LE which simply tracks the master branch in nightlies instead of following Alpha releases (these days we start formal releases at Beta) and official Kodi binaries finally being released once the build issues are resolved.
Is there a way to pass kernel options or modify filesystem node parameters for the KMS to customise these settings?
I have fuzzy recall RPi5 uses 10-bit internally padded to 12-bit for output in some circumstances as the SoC doesn't natively support the required 10-bit output. There is some upstream work being done to improve output from Kodi which might indirectly influence things, but the direct and short answer to the question above is "No"
I'm not aware of any reason the update should not work, but Kodi doesn't support downgrades so systemctl stop kodi && cp -R /storage/.kodi /storage/.kodi-12.2 before doing a manual update will clone the Kodi folder and give you a simple way to revert back to 12.2 if you need to.
It looks like CONFIG_KASAN=y snuck into a kernel defconfig and this increases the KERNEL size to a point where standard vendor u-boot configurations (as used with Android STBs) will fail to load the kernel and fault. This is nothing to do with RAM size.
I have a large list of changes to work on and current progress is rather slow, so I will update images at some point soon, but to avoid breaking promises I'm not going to give a timeline on when.
Collabora are working on broader colour support, but there are background kernel colour UAPI changes at the same time so it's likely to continue for a while to allow for things being merged in a sensible sequence. There is also development on multi-core support which is a requirement for 8K (an 8K image is essentially 4x 4K frames being parallel processed). I also haven't seen any signs of people working on AFBC yet, but that will also be needed to reduce memory bandwidth requirements.
Configure the OneForAll to behave like an IR6/MCE remote. Configure the flirc reciever to use the Kodi profile and go through each button of the profile to map what the remote sends for that button to what the receiver sees. Kodi should then work using the MCE remote profile without needing any XML fiddling. It's a PEBKAC issue not a kernel issue.
If there was an issue with MyVideos144 requiring a change to be reverted the outcome would be an increment to MyVideos145 not rollback to MyVideos143. So the more plausible explanation is that something changed since Alpha3 which resulted in MyVideos incrementing to 144. If you want everyone on the same version you either need an older LE nightly that still uses 143 or you need to bump the other devices to Kodi nightlies that now use 144.
We aren't going to touch LE12/12.2 images again as development shifted to LE13 aeons ago. So the first thing to do is retest with a current LE13 nightly. If the issue is resolved, great. If the issue remains, you need to share proper technical details on the problem, i.e. debug logs from Kodi and/or Tvheadend that reveal what the possibly-changed magic stream format is. Until then the not-good answer to your not-good question is "Yes, shitloads changed in ffmpeg between releases" because the ffmpeg major version has been bumped and ffmpeg is a rather busy active codebase. Kodi is tightly integrated with libavcodec (not the static 'ffmpeg' binary from the tools add-on) so even if you did self-compile an LE image with an older ffmpeg version inside you're likely to cause other breakage. I'm 100% confident the unknown problem has nothing to do with an arm vs. aarch64 change.
The memory cap has been removed in RK images for a while now but we don't parse exlinux.conf during updates so if you installed with the cap it will be there until you remove it.
Your guess is as good as mine on HDMI 2.1, but with the HDMI association veto'ing AMD's implementation I doubt developers will spend time on it due to the high probability of rejection and/or being sued. Was there a specific capability you were looking for?
Hey chewitt, I think I've seen you somewhere else lately...
I have my fingers in a few pies 
I'm suggesting to experiment with LE running on bare-metal from a USB stick because I'm not interested in troubleshooting VM problems unless the hardware actually works in our distro. If you continue with LE, you can run commands via SSH, either over SSH from a console, or in a web browser if you install the TTY service addon from the LE addon repo.
If you want to experiment with Tvheadend on other distos that's also fine, but out of scope for this forum.
