HDR saturated colours was solved on all platforms months ago (before the summer). Go update to a current LE13 nightly.
Posts by chewitt
-
-
The log looks like the device is continually trying to realign audio/video. That's either something from the Jellyfin server or perhaps the network, but my guess is this is about CPU load. It's not clear if you are running Jellyfin on the same RPi? (the Docker add-on is there but we don't list its containers anywhere) but I do notice that 1080p media is being played at (and thus scaled to) 4K.
Implement the whitelist and recommendations here: https://wiki.libreelec.tv/configuration/4k-hdr. This will result in a 1080p home screen and 1080p media playing at 1080p instead of being CPU scaled to 4K. This might not be cause, but as most skins are 720p or at most 1080p native GUI performance will be improved anyway, and it's good to rule this out.
-
There are two 'host' options in the file. One is IPv4, the other is IPv6.
-
Technically WireGuard has no concept of client and server since both ends are just network interfaces that route traffic. However as most users struggle with that, VPN providers and the wiki still abuse dial-up terminology; where the VPN provider operates a server and the LE device is the client. If your VPN provider only provides FQDN's for their host servers you will need to resolve them into an IP and use that, because ConnMan does not currently accept an FQDN as input.
-
Read #102 again (slowly if needed).
-
"Host" is the IP (not FQDN) of the server that you are connecting to, see: https://wiki.libreelec.tv/configuration/wireguard
-
f1gogata It looks like the edge2 u-boot defconfig set options designed for Android and this is the cause. I've defined an override in the Rockchip u-boot config that should fix that and the image in my test share is updated. Please download and retest.
-
I'm happy to test patches or nightly builds if that helps.
I have no input on anything Allwinner, but the first action is always to test the latest available dev image and see if the issue persists or has magically fixed itself. Also check HDMI-CEC options in Kodi as the libCEC versions have bumped.
-
Just curious, will these changes also improve subtitle positioning, especially when switching between different aspect ratios?
As long as the subs are the kind that can be positioned (and not baked in) it should be possible to keep them above the video instead of them being half in/out of the letterbox.
-
If I try to enlarge the image—for instance, to minimize the black bars at the top and bottom of the video—it doesn't work. Adjusting the "zoom amount" has no effect whatsoever. Is it possible to fix this?
K23 will indirectly solve that kind of thing (and likely confuse people):
https://github.com/user-attachments/assets/2b5e5703-e6e7-4992-9a3f-2a834a93145f
-
this is log with U-Boot 2024.07 dd to - LibreELEC-RK3588.aarch64-12.95.1-khadas-edge2.img
How does a 2024.07 log help me understand the issue with 2026.10?
NB: If you are using images from my test share updating with LibreELEC-RK3588.aarch64-12.95.1-khadas-edge2.img (not the .tar file) will update the u-boot version installed on the boot device. Current images use 2026.10 with upstream AT-F not rkbin.
-
Armbian can update spl to linux bootong which is relevant for libreelec.
SPL = Secondary Program Loader (BL33) = u-boot
LE compiles and ships its own u-boot. There is no requirement to boot/use Armbian for anything first, and if you are using other distro boot firmware your LE install receives no support because we have no idea what was patched into their u-boot source. The only requirement is that you erase any u-boot in SPI flash (because this will always take precedence over u-boot on SD/eMMC).
-
f1gogata please retest with the latest image in my test share. If there is still the same issue with 2026.10 u-boot please pastebin the full UART boot output (don't snip anything). I've swapped to upstream AT-F from rkbin to enable HDMI-RX support so this might (or might not) change anything.
-
CE's work is not so relevant for mainline use as it builds upon the Amlogic BSP kernel. However recent work done by CroqueMr and dangerouslaser *is* relevant and [email protected] support for P7/FEL using DRMPRIME/GLES on RK3588 rather than EGL/VAAPI on x86_64 hardware has already been proven. Further work on packaging and refinement is needed before I think about test images.
Initial patches for 8K support on RK3588 were submitted to the mailing list last week, building on multi-core vop2 changes which are still being iterated. If Ugoos want to send SK3 samples they are welcome to, but I have no way to test 8K media without purchasing a new TV so for now I'm more interested in advancing open 4K support that works on all RK3588 boards than reversing the proprietary approach needed for 8K on RK3588S2-DV silicon.
-
Do I have to update my system or worry about the vulnerabilities?
Nothing in the OS uses PHP and the laughably weak certs were revoked upstream so there is nothing to do. If you have installed containers that use PHP that's your responsibility to check and update if needed.
-
maranzon what has your RPi5 problem got to do with Amlogic?
-
Does anyone know how to get cover artwork to display when playing a audio cd?
Code the feature and submit a pull-request to https://github.com/xbmc/xbmc for merging.
-
LE13 nightlies have been stable for a long time. I don't think the family daily-driver RPi5 has run an official release since LE12.0.1.
