LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    On the Pine64 Rock64 (RK3328) the slide show does not work, but just displays a black screen. Not sure if that is a kodi issue or if it has something to do with libreelec.

    kodi.log contains an error as last entry:

    Code
    2025-12-07 20:44:21.115 T:1049     info <general>: Loading skin file: SlideShow.xml, load type: KEEP_IN_MEMORY 
2025-12-07 20:44:23.840 T:1073    error <general>: EXCEPTION: Kodi is not playing any file

    rdorsch slideshows are probably using shaders which might have a connection to e.g. the mesa version, but in general it sounds like something that needs to be investigated from the Kodi side; especially with Piers technically still in a pre-alpha state. It's worth seeing if the feature works on another distro or platform.

    Let me also add the debug log:

    Code
    2025-12-08 09:44:38.631 T:1056    debug <general>: Keyboard: scancode: 0x1c, sym: 0x0d (enter), unicode: 0x0d, modifier: 0x0 
2025-12-08 09:44:38.632 T:1056    debug <general>: bool CInputManager::HandleKey(const CKey&): return (0xf00d) pressed, window 10002, action is Select 
2025-12-08 09:44:38.653 T:1056    debug <general>: Activating window ID: 12007 
2025-12-08 09:44:38.653 T:1056    debug <general>: ------ Window Init (SlideShow.xml) ------ 
2025-12-08 09:44:38.653 T:1056     info <general>: Loading skin file: SlideShow.xml, load type: KEEP_IN_MEMORY 
2025-12-08 09:44:38.659 T:1301    debug <general>: Thread BgPicLoader start, auto delete: false 
2025-12-08 09:44:38.659 T:1056    debug <general>: Loading the current image 7: /storage/fs/pictures/BCN/2025-09-11-20-14-53-729.jpg 
2025-12-08 09:44:39.061 T:1080    error <general>: EXCEPTION: Kodi is not playing any file 
2025-12-08 09:44:39.062 T:1080    debug <general>: [plugin.video.youtube] Clear property |plugin_sleeping| 
2025-12-08 09:44:39.063 T:1080    debug <general>: [plugin.video.youtube] Set property |plugin_sleeping|: 'true'

    Full log


    What might be also interesting to add: The preview for the images works well. Even it is used as background with overlays when navigating through the image works well.

    Probably a different issue:: during scanning of the images a popup window with a progress bar is shown. During the scan the entire screen is flickering from time to time. I could not identify a pattern though.

    I don't have easy access to another platform with Piers, but the slide show does not work at all, so it should be easy to check.

    Edited once, last by rdorsch (December 8, 2025 at 5:23 PM).

    I've pushed updated images for RK356X, RK3576, RK3588 to my test share. These are now using Linux 6.18.1, and the v4l2_request patches currently being upstreamed to FFmpeg not the patches LE has used in recent years. FFMpeg devs have requested a few things to be moved around in code to align with their standards and this has surfaced an issue where Kodi shows visual glitches in video when OSD objects like vol up/down, navigation bars, etc. are overlaid on the screen. We have already figured out roughly what the underlying issue is, but it might take a while to come up with a proper fix. On the upside, the latest patches add FFMpeg support for the hantro AV1 hardware decode IP block on RK3588.

    Two steps forwards, one step backwards :)

    I've pushed updated images with some initial WIP support for VP9 hardware decode on RK3588 (limited to Profile 0 = 1080p). The codec driver has literally been found hiding in plain sight on GitHub earlier today; the work of a Computer Science undergraduate who has been working on Android images for recent RK boards. I am yet to chat with the author about his plans, but there are code and reddit comments about wanting to add 4K support and upstream which sound positive.

    NB: If the driver matures a little more it should be reasonably simple to extend support to RK3566 and RK3568, but RK3576 uses a newer IP block that is "similar but different" enough to need a separate driver.

    Kwiboo has given me (and thus you) some patches to test that fix the glitching/tearing issues introduced with the latest ffmpeg changes so RK356X/RK3576/RK3588 images in my test share have been updated to include them. Go forth and report issues :)

    NB: I've also extended VP9 hardware decode (up to 1080p) to RK356X as the patch was indeed trivial. However i'm not in the same location as an RK3566 or RK3568 board at the moment, so let me know if it works?

    Quote from chewitt

    Kwiboo has given me (and thus you) some patches to test that fix the glitching/tearing issues introduced with the latest ffmpeg changes so RK356X/RK3576/RK3588 images in my test share have been updated to include them. Go forth and report issues :)

    NB: I've also extended VP9 hardware decode (up to 1080p) to RK356X as the patch was indeed trivial. However i'm not in the same location as an RK3566 or RK3568 board at the moment, so let me know if it works?

    The glitching/tearing mitigation patches appear to be working really well on the r6s rk3588s. Using the YT add-on, vp9 playback does occasionally produce a static green video output, and sometimes seeking forward/backward or restarting playback results in expected video output.

    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.

    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.

    Nanopc-t6, black screen when booting from microSD; it used to boot fine in early September 2025. The manufacturer's spyloader is dated 2024, no newer version.
    Rendering works fine, the choice between eth1 and eth2 jumps around, and eth0 is random. The driver for the new 8822ce module works.
    I have to fix U-boot by re-flashing from an old (September 1st) libreelec image.
    What do you recommend?
    Thank you for your work, happy holidays!

    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.

    Images in my test share are bumped to Linux 6.19-rc2. No functional changes are expected although I suspect some of the in-flight 4K60 patches have matured as test files in [email protected] and 4K@60 seem to be more stable. I'm hoping the new year brings upstream merges so the number of patches required reduces and become less of a juggling act.

    Thanks for the update!! I was using the firmware rtw8821a for my wifi dongle and after updating to the latest test update, the dongle no longer works. I think it was probably the linux upgrade.

    Would it be possible to add the firmware to LibreElec? I don't know if that could help with this issue. I was using the /storage/.config/firmware/rtw88 directory to manually add the firmware, but that no longer seems to be working. Also, I got the one I am using from this link

    swever the images include the latest rtw88/rtw8821a_fw.bin firmware from the upstream linux-firmware repo and nothing has changed with that in the last few months. If you have files in /storage/.config/firmware/rtw88 these override the lastest upstream files so I would suggest removing them and using upstream firmware. If that doesn't fix something; clean boot then "journalctl | paste" and share the log URL so we can look for error messages etc.

    Hi all,

    Love the project. Have a Rock 5B and appreciate the work done by countless volunteers to make this device usable.

    I'm able to boot my device but wifi and bluetooth are not working.

    Code
    [   15.633717] iwlwifi 0002:21:00.0: Detected crf-id 0x400410, cnv-id 0x400410 wfpm id 0x80000000
[   15.633734] iwlwifi 0002:21:00.0: PCI dev 2725/0024, rev=0x420, rfid=0x10d000
[   15.633739] iwlwifi 0002:21:00.0: Detected Intel(R) Wi-Fi 6E AX210 160MHz
[   15.633803] iwlwifi 0002:21:00.0: Direct firmware load for iwlwifi-ty-a0-gf-a0-89.ucode failed with error -2
[   15.633809] iwlwifi 0002:21:00.0: no suitable firmware found!
[   15.633812] iwlwifi 0002:21:00.0: iwlwifi-ty-a0-gf-a0-89 is required
[   15.633814] iwlwifi 0002:21:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

    Here's the full log from my device: https://paste.libreelec.tv/expert-coyote.log