Does the new Linux exploit affect settop boxes running Libreelec or OSMC?
LE = technically no because we don't have sudo so the exploit chain is incomplete, but as stated above, everything already and intentionally runs as root so there's no need to use the exploit in the first place.
OSMC = someone else's distro, go ask them in their forum.
There's an RPi4 build in my test share too; probably not as current as the RPi5 one but close enough. I find the OSD tonemapping to be a little off on RPi5 hardware compared to e.g. RK3588, e.g. the OSD panels that are normally ~85% transparent are more like ~65% and need to be darker, but everything is still work in progress. I didn't specifically check for the leak in a while but that's because things have been behaving so that's probably been resolved. Go test and report back.
In the current state with audio working SSH into the box and run getedit create .. and this will rig the box to believe this specific TV is always connected; thus allowing the audio to be detected even when the TV hasn't been turned on yet or is still starting up.
Is anyone else running into an issue where the screensaver kicks while playing a video, and it's not possible to get out of it?
I've not seen this on any of the platforms that I use regularly. I'd stop and rename /storage/.kodi out of the way and then start over with a clean Kodi instance. Stop/copy/move config and bits back until you find the offending change.
AFAIK the EmuELEC distro uses the Amlogic legacy boot process so if the box is currently booting LE then the u-boot environment is adapted to LE boot files and you'd need to (re)trigger recovery boot so that Amlogic u-boot reads their bootscripts from an SD card, which will modify the u-boot environment to work with their boot files/names. Beyond that, it's best you contact EmuELEC devs for support (I'd assume it has a forum somewhere) because I've never downloaded it or booted it on anything.
So the GUI plane is active (as expected) and in AR24. So hopefully XRGB8888 can be handled.
So the GUI plane supports XR24, but the Video plane does not (YUV things only) so next step is to run kmsprint | paste when the emulator is playing (and screen is dark) to see whether the plane is AR24 (default for Kodi) or XR24 .. or what. At that point we need to ping garbear for guidance on what's normal or correct.
debug <general>: bool KODI::WINDOWING::GBM::CDRMUtils::FindPlanes(): Using video plane 41
debug <general>: bool KODI::WINDOWING::GBM::CDRMUtils::FindPlanes(): Using gui plane 38
...
debug <general>: GameClient: Loading game.libretro.uae2021 in standalone mode
debug <game.libretro.uae2021>: Setting libretro pixel format "XRGB8888"Run modetest | paste and share the URL. I'm not familiar with retroplayer internals but let's see if plane 38/41 are supporting that format (IIRC, XRGB8888 = XR24). I'm blind guessing at the problem though.
NB: Do other emulators, e.g. something simple like a SNES one, work or show the same issue?
PR is merged 
[Unit]
Description=nfs-y-script
Requires=network-online.service
After=network-online.service
Before=kodi.service
[Mount]
What=192.168.1.2:/y
Where=/storage/y
Options=nolock
Type=nfs
[Install]
WantedBy=multi-user.targetThe Either use '-o nolock' to keep locks local, or start statd message comes from the underlying NFS libs but systemd knows whatever follows Options= is an option so you don't need to provide the -o prefix to nolock.
rozpruwacz please retest using an image built from the amlogic branch in my GitHub LE repo or add the hbiyik/reardonia Kodi patchset that you find in that branch to the test image.
Investigate manual mounting of an NFS share from the console. Once you have that working .. translate the working config into the required systemd mount file options. Pay particular care to the NFS protocol versions being used because modern kernels (client) might make assumptions on infrastructure (server) supporting equally modern versions of NFS, and if SMB is unperformant you probably have old server hardware running old server software. In my experience SMB works fine unless the underlying network environment is poor, and the cure for that is always fixing the environment not swapping protocols 
Please see if this LE13 image solves the issue? https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz
Is it possible that LE 13 doesn't support TvHeadend?
Tvheadend 4.3.x is widely used and we track upstream changes. It's always possible that upstream breaks itself, but as a general rule that kind of thing is a rare event.
I'd guess the add-on is checking for keysize even though it's a long deprecated option. You should flag the problem to the add-on maintainer through their GitHub issues list. The add-on is not managed by LE project staff.
What LE version? .. and does the Kodi GUI show correct (summer) time?
Also provide a Kodi debug log.
The "getedid create" process should work the same on all hardware we support these days; perhaps with a few niche exceptions among ARM SoC boards, but AMD cards should be fine. There's no harm in experimenting anyway and "getedid delete" will always clear-up the applied config if it didn't work.
then it looks like an FFmpeg bug to me:
In logs "error" does not always equal a fatal problem. In fact most of the time it is nothing more than the application following some kind of if/then/else decision tree when processing data. Is the file mp3; no (so log error on that path, keep processing) is more likely to be the cause (or something of that nature). If you read the log further the file is clearly being played so it wasn't fatal.
BokitoNL You didn't share the output of pastekodi so we don't see the system log (only kodi log) but I'm not seeing anything in the kodi log to indicate an HDMI output problem. I would advise to check cables and ports and also ensure config.txt is in a clean or default state without any kind of helper overrrides being used.
