LE/Kodi 19 testing on RPI4

  • Hello,

    I am testing on RPi4-2Gb RAM, Kodi 19 / LibreELEC-RPi4.arm-9.80-nightly-20201002-85830fd.tar with an 4K LG Tv.

    At first look I found this issues :

    - Noresolution higher than 1920x1080 60Hz available, I don't use: hdmi_enable_4kp60=1.

    - If I set hdmi_enable_4kp60=1, LE boot but screen it is black or Tv did not recognize HDMI source at reboot.
    - custom ../userdata/keymaps/remote.xml it is ignored.

    No other problems found yet.

    Edited once, last by myrpi: fixed wrong image name (October 2, 2020 at 10:11 AM).

  • You seem to have linked to the wrong image, for RPi4 you have to use the RPi4 images - eg LibreELEC-RPi4.arm-9.80-nightly-20200924-4722b9e.img.gz

    4k support isn't implemented in the driver yet, that's being worked on and will come later when it's finished.

    We are currently testing kernel 5.9 with a newer version of the display driver and changed the config a bit so you won't get a black screen with hdmi_enable_4kp60=1 in config.txt. With current nightly test images you could add disable_fw_kms_setup=1 to config.txt to avoid that issue - see linux (RPi): update to 5.9 by HiassofT · Pull Request #4562 · LibreELEC/LibreELEC.tv · GitHub

    Not sure about the remote.xml issue, you'll have to post a kodi debug log. ./userdata/... looks wrong though, that should be /storage/.kodi/userdata/...

    so long,


  • I fixed the image name... I did upgrade from current image to latest nighty and not clean install so I used tar buid.

    yes path it is correct, I did not typed all.

    this is the remote.xml I used until now.

  • If you updated from an older version please replace your config.txt with the one in /usr/share/bootloader/config.txt - some important settings have changed and the file isn't automatically updated/replaced yet.

    as for remote.xml: please provide a kodi debug log.

    so long,


  • config it is the same, except I have allocated higher mem for GPU 320k

    I found in log:

    I fixed removing all xbmc. from remote.xml

    Edited once, last by myrpi: fix (October 2, 2020 at 10:55 AM).

  • keep GPU mem as it is (76MB) - that's not needed with the new driver and only wastes memory.

    Only H264 HW decoder needs GPU mem and 76MB should be plenty for it. New driver needs CMA memory (which we already default to 384MB ATM).

    so long,


  • 4k support isn't implemented in the driver yet, that's being worked on and will come later when it's finished.

    Now that Kodi 19 has arrived in the nightlies, does that mean that proper 4K support is almost there? And a related question (which must have been asked before, but I couldn’t find an answer): Will LibreElec support HDR?

  • Currently no 4K and no HDR, the focus is on getting 1080p decoding and seeking working reliably. Both will be added later (no ETA on when, there are a lot of depdencies).

    Thanks for the info, though! Just out of curiosity: Full HDR support is just a matter of software development and not a hardware problem, is that right?

  • spooker thanks for the heads up, I had a look at the log but unfortunately nothing was logged in the ~30sec where you played the video (which isn't your fault but makes it tricky to find out what's going wrong).

    Can you try disabling hardware acceleration in settings->player->video (you may need to change settings level to expert to see this option) and test if audio is played fine?

    I have seen audio drop-outs with passthrough in the past when using H264 hardware decoding, but last time I checked was before the recent H264 seek changes. Still it would be good to know if audio with software decode instead of hardware decode is fine.

    Edit: ah, and it would be great if you could reproduce the issue with some publicly available sample (and post a link) or upload a short sample file so we can try to reproduce it locally.

    so long,


  • Thanks for the fast response Hlias.
    I added a second log in
    DTS-HD-MA pass-through is choppy in Kodi 19 [LibreELEC-RPi4.arm-9.80-nightly-2020122]

    I disabled hardware acceleration like you suggested and yes this seems to fix the issue.
    I will try some tests with some DTS-HD demo samples and hardware acceleration enabled to see if I can reproduce this and report back. In the meanwhile if you have any location with audio samples that you actively use please point me to it.

  • The dropouts have almost disappeared but are still there. To reproduce you need to play the audio sample several times to make it happen. In movies that are by definition longer in length this is more apparent.