Kodi has a native webOS app which seems to be a less ambitious or invasive approach 
Posts by chewitt
-
-
the output of the signal is RGB 8-bit
DV is tunnelled (hidden) in RGB 8-bit frames, not 10-bit, so that's correct.
-
atirage21 I have better things to do than download and open random log files to guess what undescribed issue I might need to look at. You can stop posting them because I don't ever look at them.
-
maranzon I'd suggest updating to the latest firmware via the flirc config app; and if that doesn't change anything log a ticket with the flirc support team as they are the experts in their products. The first check on most support flows is "is the user running the latest firmware? - if no, update" so tell them you already did that in the ticket opening.
-
I'm describing the impact of 1080p desktop and 1080p+4K whitelist configuration. The TV panel is 4K native, but also accepts input in 720p and 1080p and will scale that (using its dedicated scaling hardware) to the native 4K resolution. If Kodi scales, it generates load on the LE device. If Kodi outputs 1080p and the TV scales, the TV takes the load. In almost all cases the TV will do a better job, so let it handle 1080p > 4K scaling and benefit from faster navigation and lower overall load. Scaling SD/720p to 1080p is trivial so Kodi can be used for that task.
-
Feel also free to just pick and rename the patches or do what you like with it.
I really would like to have this upstreamed.
-
HDR saturated colours was solved on all platforms months ago (before the summer). Go update to a current LE13 nightly.
-
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).
