If you write LE13 on the eMMC, it is not guaranteed that you will be able to boot older versions.
The Amlogic vendor kernel has some drivers that assume an era-appropriate vendor u-boot is installed so it can probably be done with a little manual fiddling (which there are no guides for) to fix wrong-named boot files, but I guarantee that some drivers don't work right, and as the maintainer of the AMLGX image; this is not something we have any interest in trying to support.
Well done developers, I really like what you have done.
Credit is more likely due to Tvheadend devs or Kodi pvr.hts devs. All we do is bump the add-on as updates are pushed 
No fix yet, although it looks like Intel devs have finally grasped/believed the problem after we posted a recent update to the bug report on their tracker, so maybe we have some test patches to play with in the near future.
2026-01-25 21:12:52.489 T:1107 error <general>: ffmpeg[0x3700b3f0]: [hevc] frame_post_process: Decode fail
2026-01-25 21:13:40.973 T:1129 error <general>: ffmpeg[0x3706d650]: [hevc] frame_post_process: Decode failThe file is "Irgendwie Schwanger (2025).mkv" ? .. If yes, this ^ is recorded in the logs (two different plays of the file). You'd need to enable ffmpeg debugging in Kodi logging settings to perhaps see more info about the media stream - that might show if there are other issues or oddities in the file, e.g. from bad encoding.
If you have a spare SD card, test the same file with an LE13 nightly and see if that makes a difference?
But i can't edit it with an editor. When i just open and save it back, the file gets bigger and booting from sdcard doesnt work anymore.
It's a compiled binary file (albeit one with lots of readable strings inside) so when you 'edit' the file you break it, and because boot depends on this file, boot from SD is broken. Like all compiled code, the source file can be edited, then it needs to be recompiled when you create the image.
sky42 maintains an LE image for x86_64 devices that includes support for encrypted drives (our default image intentionally does not support this). The drive needs to have a Linux filesystem, e.g. EXT4 and be locally mounted. You can then share the drive over SMB if desired but as it's already locally mounted there's no value (only pain) in trying to locally mount the drive a second time as a remote SMB share.
Have a read of his thread LE 12 added lvm2, luks (dm-crypt, veracrypt, bitlocker), mdraid, ext4 encryption
It looks like groundwork for USB support is here: https://patchwork.kernel.org/project/linux-…[email protected]/ and that series has been merged for Linux 6.19.y which we will bump LE13 nightlies too in the next month (once it ships) but looking at https://github.com/morrownr/rtw89 quickly I don't see obvious patches for RTW8922AU that could be simply picked on-top to add support, but if that codebase works then I'd be reasonably confident of support coming in the next couple of kernel cycles as the developers working there are quite active and constantly chipping away at upstreaming.
For the rtw88 driver we intentionally disabled the incomplete in-kernel driver in favour of using the lwfinger/rtw88 dev branches for a while, but that allowed us to drop older Realtek vendor drivers at the same time, so the additional hassle of regular bumps to keep track of development was acceptable. I'm not sure we want to repeat that for rtw89, but if you can build an LE images and look at git history to see how rtw88 was handled it shouldn't be too hard to add support.
IIRC the WeTek Play/Play2/Hub boot mode is toggled between WeOS and LibreELEC on SD card by pressing the power or pause (can't remember which) key on the remote while the WeTek splash screen shows. The boot choice is then remembered until you either remove the SD card and it will default back to WeOS/Android or you repeat the remote-key toggle. Using this original boot flow it will not auto-boot into LE simply by inserting the SD card. If you boot CE or the dtech image using the typical "toothpick" boot method the boot flow will be modified to boot on presence of SD card, but the LE 9.0 image will not do this as the autoscript files on the SD card do not have the instructions to modify the boot flow.
TL/DR; the issue was "PEBKAC" due to incorrect assumptions (based on some other distro) on how things work.
There is no underlying desktop environment in LibreELEC so if you saw a mouse cursor on-screen Kodi started. If the home screen did not then show, the kodi.log (hopefully a debug one) and/or the systemd journal might have clues. This is probably past-tense though and I've not seen anything similar; other than the Kodi database upgrade screen. NB: I'm not aware of anything in images that would result in kodi.service being disabled.
I'm not aware of any general issues with freezing/stalls on N100/N150 devices. There are less than a handful of reports with that kind of issue and most were triaged to some form of PEBKAC, or AI analysis of kernel crashes points to buggy wifi drivers (which newer kernels in nightlies might resolve) or users failed to provide meaningful information to investigate.
TL/DR; The latest nightly would always be the staff recommendation. The only known issue is a long-running one with [email protected] playback and pass-through audio on HDMI connections, but that has a known workaround (reducing display bit-depth).
If you then see issues, report them.
Test share images are updated with Linux 6.19-rc6 and a notable fix to gracefully handle uninitialised values during HEVC decoding which helps with 4K media files that spammed the system log with errors. I'm now able to play all the HEVC media in my test-file collection which includes a number of known-bad files. Playback of those sometimes takes 10-15 seconds to start, depending on the underlying kind of broken, but even those play which is great. That fix (the result of AI analysis of kernel splats) also pointed fingers to some related code that can be improved to not allow the uninitialised values in the first-place, so we should see some additional fixes on the mailing-list in the next week.
At this point the only things I feel are missing from RK3588 are HDR and hardware deinterlacing. The former will eventually happen through work Collabora are doing. Nobody is handling the latter though.
I'm back to buffer size AI guesswork and nagging Jonas to review old patches for older hardware so we can get closer to a unified kernel source for aarch64 boards.
See https://patchwork.kernel.org/project/linux-…@collabora.com/ for the main patches that added CEC support upstream, but there are follow-up fixes and everything becomes entwined in other DRM bridge work so backporting patches to an older kernel would be a painful task.
Thankfully current kernels have everything merged, so LE13 nightlies (6.18) and images in my test share (6.19) should have working HDMI-CEC support.
I installed LibreELEC on the ThinkCentre, then copied the Kodi configuration from the Pi.
For the sake of experimenting: stop Kodi, move /storage/.kodi to /storage/.kodi-old and restart Kodi. This gives you a clean Kodi install (reverting is just the reverse procedure). Configure the HDMI output and reboot a few times. Does the issue still occur?
Things work better on LE due to the OS being overall lighter and because Kodi setup with adjust-refresh and whitelists etc. requires less compute resources during playback than a desktop app under wayland that's forced to resample audio and video to run at the desktop rate of 1080@60Hz or 4K@60Hz.
The buffer size issue is the main thing to focus on for VDPU346. The VP9 patches seem to work well and I'm coaching Abhi Sarma on kernel etiquette so hopefully a v1 series can be sent for review soon.
The minor tearing/glitches that can be seen when the Kodi OSD is active are the result of refactoring in the ffmpeg patches (dealing with ffmpeg developer feedback/requirements) and additional work in Kodi is needed to get back to the previous state where there were no artefacts. More patch series need to be merged down, then some effort can go into investigating that.
Did you backup the RPi4 and restore to the ThinkCentre? or make a clean install on the ThinkCentre?
I've read the feedback. I'm still experimenting with AI tools to see if they can bridge the gap in my rather lightweight coding skills or we have to resort to nagging Collabora folks to take over (or cap the current driver at 1080p to get an initial merge).
HDR works, 8-bit only? (HDR is better when 10-bit but it's not mandatory) as RK3566/68 use the older Rockchip HDMI IP which has more colour support upstream. The newer one used with RK3588 etc. is still missing some infoframe handling IIRC.
btw, Jonas believes https://github.com/torvalds/linux…2fdfc001d044bee might have resolved the "wiotlb buffer is full" IOMMU issue that requires RAM to be capped under 4GB. I'm going to remove the cap on my boards and see if I still get a load of weird errors. Please do the same on your LE images.
docker run --rm --log-driver none -v `pwd`:/build -w /build -it libreelec make image^ from documentation, no script required. User claims Docker proficiency so you have to draw the line somewhere 
Read: https://kodi.wiki/view/Internet_video_and_audio_streams
Create .strm files for each Soundcloud URL that you want to use as media. Kodi treats these like a media file with no metadata.
Create .nfo files for each .strm file. This is required. It also provides a way to add metadata, e.g. pretty names, if wanted.
Scrape the .nfo files to the Library.
Add Library items to a playlist.
Do something with the playlist, like script it being started 20 seconds after Kodi starts (how you do that is .. Google'able).
Plan B .. get a Raspberry Pi and use one of the many good niche distros or RPiOS installable apps/containers designed for "signage" use-cases, as that appears to be the end goal and something Kodi is not really designed for.