Posts by chewitt

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.

Quote from essetikappa

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 = True

N2:~ # 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.

Images for RK3588/RK3576/RK3568/RK3566 have been updated with hardware deinterlacing support. Watching the Winter Olympics and F1 pre-season testing from DVB sources that use 1080i is now hugely improved. I'm also investigating pass-through audio support on RK3588 and RK3576. Formats like DTS and Dolby Digital that use 6-channels (5.1) are working but the 8-channel (7.1) HBR formats like TrueHD and DTS-MA are still handled as PCM and anything with Atmos seems to result in no audio at all. This probably points to the HDMI driver missing support for the 8-channel packing/handling needed for HBR audio, but Claude seems to think the driver can handle this already so more digging is needed.

Images for RK3399 and RK3328 are now created from the same Linux kernel source as RK3588/RK3576/RK356X. Merging the patches has needed some guesswork from me in a few places. It all compiles, so must be good? - I am interested to know about regressions on RK3399 and RK3328 boards as I don't have board samples and depend entirely on your feedback. I am keen to know about things that don't work now, that did work on images in recent weeks/months. Things that have never worked or missing for ages are still nice to know about, but are a lesser concern.

Images for RK3288 are not updated as there are some compile failures on Linux 6.19.y that I need to investigate.

NB: As part of the pass-through experimenting I changed the alsa config used, and the new one changes the names/presentation of audio devices to Kodi. After updating you will need to reselect an audio output in Kodi.

DeViLRuNNeR-dev there are now 200+ patches in my Rockchip 6.19.y kernel branch so I can't put my finger on specific things that make PCM output work on that hardware. I do know that working multi-channel PCM output is not a new thing for LE images, it's been around for a few months now.

In post #1 you state that crossfade works. In post #3 you state crossfade doesn't work.

I'll let someone else take up support from here.

inputstream.adaptive installs inputstreamhelper (widevinehelper?) which handles downloading the chromeos image we have to extract libwidevine from the first time an add-on that requires it is used. I'm using IA on an RPi5; which uses exactly the same IA addon as RPi4 (same files/repo). I'm using it on an LE13 image, not LE12.2, but that shouldn't make any difference as the add-on versions are kept in sync.

If something is failing there will be info in kodi.log.

As 99%+ of users will use the Generic album scraper to scrape their albums, it makes sense to include it in the embedded filesystem instead of incurring bandwidth and the inconvenience of having to download/install it. As Mr Spock says .. "the needs of the many outweight the needs of the few".

If you want to remove it you need to compile your own custom LE image that omits it as a default installed item. You are welcome to do that (all the sources are public and GPLv2) but staff aren't going to be too interested in spoon-feeding instructions, you will need to figure out how on your own. The easier option is to ignore it and/or don't use the generic scraper.

Soundcloud is an online audio source and not an album in the local music database; which is where Kodi stores knowledge of an album and album volume preferences. If you want to set a persistent volume level for all soundcloud objects, or soundcloud album objects, you need to make a feature request to the add-on maintainer via the Soundcloud addon support thread in the Kodi forum; and then wait patiently until someone investigates, and if possible and you are lucky, implements the feature.

Some users desire complicated lives

Although they are add-ons, they are 'core' Kodi capabilities and Kodi expects them to be present, hence they are pre-installed and reside inside the squashfs SYSTEM file which is expanded into a virtual filesystem on each boot. You cannot delete something that exists inside a read-only file.

LE distro packaging is not like a normal distro and we require TWO partitions; one used for boot files (KERNEL/SYSTEM, 512MB to 1GB in size, can be VFAT or EXT4) and one for a persistent /storage area (4GB+ and must support Linux permissions, e.g. EXT4). If you understand what you are doing it shouldn't be hard to reconfig free space to create the required TWO partitions, copy boot files over to the boot= partition, then create the config. LE normally uses syslinux (legacy) or grub2 (EFI) bootloaders so there are two configs (syslinux.cfg and grub.cfg) that describe the boot= (boot files) and disk= (storage) using either UUID (default) or disk label or /dev/device. I have no experience of rEFInd so have no idea what EFI configs it requires, but all bootloaders are similar so you can use the grub/syslinux configs for prior-art.

NB: This is an unsupported configuration; meaning if it goes wrong it is not our problem to solve. There is no interest in trying to implement support for installing to a single partition because users with this config have multiple bootloader options to choose from and the risk of touching partitions and trashing someone's existing Windows/Linux/etc. install that contains pics of their kids/pets/dead-relatives etc. is high. Simply not supporting it and forcing users to install LE to an entire disk is simple, long-proven, and avoids the risk and irate user support issues that follow when things inevitably fcuk up.