Commit d39e2d1 kinda describes what I am seeing in mainline/upstream kernels. How would one ask for these to be included in current-rockchip64 kernel builds?
The same change is present in the rockchip-6.19.y branch: https://github.com/chewitt/linux/…9847573205c326a used in my test images and the same will be in LE13 nightlies. If you want to have the same fix in some Armbian release (we have no rockchip64 kernel builds) go ask their devs to copy the patch from my tree.
f1gogata If you have been running Oleg's older RK images I have no understanding of how the board is booting or what u-boot versions are installed, but you probably need to a) erase the vendor u-boot that Khadas oocrap installed to SPI flash, as this has boot priority over the emmc device, and b) ensure an LE image has been written to emmc using dd to ensure u-boot 2026.01 is present on emmc to boot the device once SPI flash has been erased.
To erase SPI flash, run dd if=/dev/zero of=/dev/mtdblock0 bs=1M from any Linux OS that boots.
To write LE to emmc, boot an LE image from SD card or USB stick (so emmc is not in-use) then transfter a current LE13 image over to the /storage partition and use emmctool to write the image to emmc.
The fuzzy screenshot shows a system booted from SD card with swap devices so this is presumably from RPiOS and not from an LE install. The same image shows the NVME device has no mountpoint so while the physical hardware is visible, it probably hasn't been partitioned and formatted for use, and for the same reason it will be physically visible but unusable in LE too.
The simple fix is to partition and format the device, but are you wanting to boot/run from the NVME device or continue booting from an SD card with the NMVE drive used only for persistent /storage?
I learnt that Intel is not really supported anymore here
That might be your personal opinion, but from a staff perspective, that's a load of rubbish.
I'm reading the thread and the main developer (Florian) is asking for a specific issue to be separated and debug logs to be provided to aid triage/investigation; and while a few insults and accusations are then made, nobody opens the issue and nobody provides the debug logs; the issue is not investigated, and after some time with nobody doing as asked the ticket is closed. And all you're saying here is #metoo which doesn't achieve anything. Florian is generally helpful but also a typical software engineer with a process and methodology for investigating things. If the people impacted by a problem can't be bothered to follow the basic process he's asked for, there are many other things that need his attention and he'll keep himself busy working on those instead.
Forward motion is generated by people doing things, not talking about them. If you want your problem to be fixed, feel free to open a ticket and engage.
I've been running nightlies for the last ~2 years without drama (other than self-inflicted) despite the current Alpha tag.
Just cp -R /storage/.kodi /storage/.kodi-backup before updating and you can revert back easily.
Does this happen with LE13 nightly images? .. not that we don't care about LE12.2, but no more releases are planned/likely and K22 removed timezone support; timezone is now set through LE settings and no longer defined within Kodi.
Does Kodi have hardware acceleration to play 2K/4K if I install it on Fire TV? Do you know if I need to get the Fire TV 4K version (not the HD one) for this?
Ask in the Kodi forum where people with Andoid experience hang out. Although I'm a Team Kodi member, i'm not one of them.
I've pushed updated RK3588/RK3576 images that appear to have HBR formats "working" to some level now, although I hear some glitches on a few files that could be underruns or some kind of DP/HDMI bandwidth issue.
I don't see channel mapping issues with speaker-test -D hw:hdmi0,DEV=0 -c 6 on a Rock 5B board. Channel mapping was an issue in the past, but Kwiboo spotted the problem some weeks ago and a fix was submitted upstream.
If you see issues with SMB shares perhaps experiment with different SMB chunk size values in the Kodi SMB client settings. I see no issues with 50GB+ sized ISO rips (other than start being slower) so that sounds more like an environment or media problem.
This describes our generally recommended configuration: https://wiki.libreelec.tv/configuration/4k-hdr .. using adjust-refresh with the mode whitelist gives the best experience. There is no need to set anything in advancedsettings.xml.
There is one outstanding audio bug https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10199 for which there is a workaround hack available while we continue to pester Intel devs about a fix: https://github.com/LibreELEC/LibreELEC.tv/pull/8588.
Is it possible to install LibreElec on the FireTV (2k/4k accellerated)?
No, the underlying hardware is Amlogic but (as with all AndroidTV devices) the device requires encrypted boot firmware and the boot flow cannot be reconfigured to run Linux.
If there's a bug on multiple Kodi versions it needs to be reported to Kodi devs in their forum; it's clearly not an LE issue.
LE uses u-boot 2026.01 but with the vendor rkbin used in the boot recipe rather than TF-A which still seems to be maturing; I leave boot things to Kwiboo to guide on since that's more his thing. You should be able to achieve the same under Armbian with the same kernel/ffmpeg/kodi versions and patches and the same alsa configuration, although if using Kodi under Wayland you will be stuck with everything running at the desktop resolution/refresh rate as Wayland does not support the dynamic switch that LE uses when running Kodi GBM. NB: there are way too many patches required right now, but over the next couple of kernel cycles a large number of things should have been merged and the delta between the bleeding-edge and upstream will reduce.
I don't see anything abnormal logged; using an AMLGX image on an N2 board, with the timezone configured for Asia/Dubai or with the timezone changed to Europe/Warsaw:
N2:~ # connmanctl clock
Time = 1771724187
TimeUpdates = auto
Timezone = Asia/Dubai
TimezoneUpdates = auto
Timeservers = [ ]
TimeserverSynced = TrueN2:~ # grep -i bias /storage/.kodi/temp/kodi.log
2026-02-22 05:35:27.952 T:808 info <general>: Time zone bias changed from 0 mins to -240 mins (due to time zone or DST change).If there was a general issue with timezone configuration and ntp updates (ConnMan) there'd be a ton of forum posts on the topic; and there are a decent number of people using LE13/K22 nightlies and this is the only report. This normally points towards an issue being network/environmental related and not something in the LE image.
Have you tried rebooting your internet router?
I've never heard of people playing games on DVD discs until recently but apparently this is a real thing. I'd guess you need the JRE-Zulu add-on from the LE repo so that Java things on DVD media are possible in the first place. Then open some discs and see what happens. This is firmly at the niche end of things so no guarantees.
Feel free to use the Kodi 'snap' on Ubuntu:
a) You have the ability to remove anything you like, anytime
b) You become some other distro's support problem
From our perspective that's a win/win scenario 
https://www.kodinerds.net/ <= Kodi-unterstützung in Deutscher sprache
If high CPU is a problem the likely cause is that you are software decoding media and not hardware decoding. It's hard to triage that without being able to follow a readable log though. Logs to the JustPaste site have been stripped of line endings and are essentially unreadable. Logs to our paste site are only system logs with no Kodi log.
Your hardware should work with the Generic (GBM) image; so I would ask that you 'update' to a current LE13 (non-Legacy) image and if that didn't magically fix things, share some readable logs.