Posts by chewitt

rkman Saying "black screen" and then "rendering works fine" sounds contradictory so I'm guessing the Kodi home screen shows up eventually? so the screen is only blank during early boot?. If yes, this is prob. due to the kernel now supporting 4K output and in early boot a 4K mode the TV doesn't quite agree with is used. The workaround is to append video=HDMI-A-1:1920x1080M@60D to the kernel boot params in extlinux.conf so initial output is forced to 1080p instead. As a general rule you want to run Kodi at 1080p and only switch to 4K for playback anyway (see https://wiki.libreelec.tv/configuration/4k-hdr).

NB: If the board is booting from downstream Rockchip u-boot on SPI flash you can probably expect random behaviours. It's best to wipe SPI and allow mainline u-boot (2025.10) on the SD card or eMMC module (wherever LE is flashed) to be used instead.

ffmpeg 7.0 was updated to 8.0; the add-on repo version was already bumped and add-ons are already being built. The mpd add-on should update itself in the next 24h.

The existing config worked fine at one point but systemd is a continually evolving beast so perhaps something was improved and now needs additional config juju for things to work as before. If something needs fixing .. send a PR with a decent explanation of what is being changed and why, and it will be tested (over a range of build targets) and if good, merged.

Moved to off-topic as this has nothing to do with LibreELEC support.

orclex I've picked the details into one of my branches, it will be merged next time I push some changes to our main repo.

The contents of /storage/.config/system.d are overlaid onto the virtual filesystem after SYSTEM is expanded on boot, so if you want to change config of an embedded .service file just clone the file to that location, make edits, and reboot. The same is true for other special folders under /storage/.config/ .. or you need to start building custom images with your preferred changes baked-in during compile via the buildsystem. The former is fine for quick tweaks and tests. The latter will be easier to sustain over a longer period.

Donations to project funds are always welcome but if there's even a hint of an expectation of a donation buying special treatment or custom images; keep your wallet closed to avoid disappointment.

I'm wondering if the elfarto VAAPI shim works better: https://github.com/elFarto/nvidia-vaapi-driver/

NB: Our general advice since 2016 is to avoid the purchase of nVidia hardware for LE use due to distro packaging for nVidia support being a clusterfcuk. The nature of the clusterfcuk has changed a few times over the years, but with each improvement nVidia never fails to add some new complication that keeps the status quo intact.

If the OS is running but no graphics (and thus no Kodi) I'll make an educated guess the problem is mesa related. See if reverting to the mesa version used with the last known working images restores things? If yes, you can manually bisect between known-good and known-bad mesa versions to find when the breaking version change occurs; then you can look at mesa changelogs/commits to see what commits might be involved.

NB: I'm guessing mesa because the panfrost kernel driver has received little real-world change over time since it was added, but on the userspace side mesa has a high rate of change and mesa automated testing will be done against Bifrost hardware, and perhaps the second generation Midgard T860 used in some Chromebook devices; not the first generation Midgard T628 used with XU4 which has an inconvenient amount of silicon "errata" that often require complex or fugly workarounds.

The Lakka folks had images with Mali blobs in the past and I have fuzzy recall of there being some older LE community images from zalaare but our official releases always used upstream kernels and mesa/panfrost.

Read this: https://wiki.libreelec.tv/support/update

If you’re lucky it’s missing firmware. If you’re unlucky it’s the older Broadcom driver that we dropped. Share the URLs generated by “dmesg | paste” and “lspci | paste” and we should be able to see.

The first official XU4 image was LE11 (10.95.1 = LE11 beta1) so there is no 9.2 image and CrapGPT is halucinating answers. The last time I dug one out for testing was about 12-months ago and at that time Audio/Video were working fine; albeit XU4 is showing its age and only supports H264 hardware decode. NB: The main reason we still have it in our board line-up (and also the main reason we added support back in 2020) was so that Lakka can use it for retro-gaming.

You’re not a normal user though. That’s the point. LE is also no different to RPiOS when it comes to defaults here.

Updated images in my test share now run Linux 6.18.2 and after some collaborative VP9 fiddling with the driver author this morning all the YUV420 8-bit/10-bit VP9 test media I have now plays fine on RK3588 (no more green screens) although whether we managed to correctly enable 'Profile 2' support in the driver is anyone's guess. On RK356X I'm seeing some IOMMU page-fault issues with 10-bit HEVC media. There's also an issue on RK356X where fractional rates (23.976/29.97/59.94) are not showing up in the kernel DRM layer. That can be worked-around by disabling adjust-refresh and allowing Kodi to run at 60Hz. Both of those will need some looking into. And i've not tested with RK3576 for a while, something still to find time for.

CD/DVD is not supported in our boot media. Have you tried creating a bootable USB stick instead of an SD card?

The work-in-progress VP9 driver implementation is loosly based on the older 'rkvdec' IP block for RK3399 boards which was limited to 'Profile 0' media (8-bit, YUV420, up-to 1080p). The driver has been extended to work with 4K media, but needs further work to support 'Profile 2' (10-bit) and the DRM layer on RK3588/RK3576 does not support YUV422 yet. The driver author also needs a little coaching on how to run the 'fluster' tests that are used to score conformance and capabilities. It's a promising start though.

Quote from arminfuerst

Thank you, that solved it! I wonder why this is disabled by default and there is no way to enable it through the UI?

Everything requires CPU cycles to exist and only a handful of RPi users require analogue audio so it defaults off. For much the same reason, why go through all the development effort to make overlay application a GUI task when few will ever use it.