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.
I'll state the obvious first: we don't officially provide any support for running LE in virtual environments. The Generic OVA exists to support occasional GUI oriented dev work; e.g. at the recent Kodi DevCon (in Spain) I've developed a Tailscale add-on by using the OVA running on an ESXi box at home (6,000km away). If users want to experiment with LE in a VM for other purposes that's fine, but there should be no expectations of support or interest (or timely bugfixes) from staff.
So, with the disclaimer done:
I would experiment with LE on a USB stick first, to prove the DVB hardware is supported, has the right firmware etc., and runs well, before add a layer of obfuscation attempting the same thing in a VM.
Google says AF9015 is a combo chip that contains a USB bridge and AF9013 demod, so Tvheadend showing an AF9013 demod is probably correct; it wouldn't care about the USB bridge.
If things are not working when running LE from a USB stick, run "journalctl | paste" and share the URL so someone who knows more about DVB things can comment.
The addon repo version was bumped from 12.80.5 to 12.80.6 about a month ago and the .5 version no longer exists (hence the error). As noted above, I'll get an updated image out sometime this week.
Using the AMLGX image "emmctool" has a backup function which is just a raw dd copy of /dev/mmcblk1. The boot0/1 devices aren't used for anything as u-boot is on the main block device so those should be all zeros, but I guess no harm to have them too.
I've been poking some interesting Amlogic things over the last week and Kodi DevCon + travelling was the weekend before. I'll circle back around on Rockchip things in the next week. You're not missing anything essential.
One part of the video stack has decided to render 1080p, another has decided to use a 4K mode so you're looking at 1080p rendered onto a 4K surface. I'm not sure what the root cause is, but this is occasionally reported against x86_64 and RPi hardware so it's likely a logic failure somewhere in the kernel DRM code rather than being something vendor specific.
Assuming HDMI is on the HDMI-A-1 connector, append video=HDMI-A-1:1920x1080M@60D to kernel boot params in syslinux.cfg or the equivalent EFI config (depending on which is used for boot). This will force the initial kernel DRM state to 1080@60, which will stop any attempts to use 4K modes during boot. It doesn't affect Kodi switching to 4K modes for playback.
As a general rule mesa bumps rarely cause problems, but we haven't built or tested that combination (nor are we going to) so the only way to find out is to go make the test build. The same will be true for any other packages you want to seek advice on.
Drive probe order is not guaranteed in Linux so if you insist on using the auto-generated mount names under /var/media there is nothing you can predict which device will be /dev/sda1 and /dev/sdb1. The solution is to not use auto-generated mount names and assign disklabel's to the partitions so they persistently mount under the /var/media/<disklabel> instead, e.g. e2label /dev/sda1 "Movies" will result in /dev/sda1 always mouting to /var/media/Movies. As long as you give each drive a unique disklabel there are no namespace clashes and you solve the problem.
No idea about clearing out old profile/settings/addon cruft that causes issues; trial and error is the only approach unless something obvious is logged in a debug log.
