Kodi 20 on bookworm can't decode 4k HEVC properly

Creating a bug report/issue

Hi, I just installed Kodi 20 on dietpi bookworm. I tested Kodi 19 on Bullseye before, and playback of 4k HEVC 10bit HDR files was working perfectly.
Now on 20, it no longer works. Video stutters and I have around 1 frame per second. I don’t know what’s the difference between those 2 installs, maybe missing codecs or missing configuration ? I noticed that decoding options present in 19 are missing in 20. Could it be linked ?
Would you have an idea of what could be wrong ? What can I do to help ?

I wanted to show some Kodi logs (although I’m not sure there would be so much interesting things), but Kodi is apparently not a registered service and I’m not sure how to do it manually:

root@DietPi:~# systemctl status kodi
Unit kodi.service could not be found.

Thanks in advance for your help, have a great day.

Required Information

  • Distro version | bookworm 0
  • Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | RPi 4 Model B (aarch64)
  • Power supply used | (5V 3A)
  • SD card used | (SanDisk ultra)

Additional Information (if applicable)

  • Software title | Kodi
  • Freshly installed
  • Can this issue be replicated on a fresh installation of DietPi? → probably
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

According to here: Choppy playback on Live Streams | Kodi Nexus on Raspberry Pi 3 Model B · Issue #465 · anxdpanic/plugin.video.youtube · GitHub

It appears Kodi for Bookworm hasn’t been built with the required codecs for Raspberry pi 4 yet. Can someone confirm this or maybe have a solution to add it ?

We don’t build Kodi on our own as we install the official version from Debian package repository. If there are thinks missing, they would need to be added upstream.

DIgging around just found generic entries on how to stop buffering

How to Stop Kodi Buffering Issues (3 Fixes Still Working in 2023) (comparitech.com)

Generic is the word, this is the example of AI-made websites that proliferate around Kodi keywords and make it unbelievably tedious to find information about anything Kodi. First things it says are installing a shady third party addon (generally piracy and dead in a few months) and using a VPN. (also “Still working in 20XX” is 100% automatically updated and I’ve never seen this to be true)

Sadly Kodi on Bookworm won’t have good HW acceleration on RPi until there is a Bookworm compatible Kodi build provided by RPi. Dom (from RPi) is working on a Kodi 20 branch already: GitHub - popcornmix/xbmc at gbm_nexus

Not sure when RPi OS Bookworm can be expected, but at least it can be tried to compile Kodi from this Git repo and branch on Bookworm. If it works better (than the on from Debian), we can provide packages. We did the same when Bullseye was released, until RPi provided them.


Hi folks, any update from the Kodi 20 branch? Addons starting to get disabled in Nexus which is a shame as I’ve got it running so well!

We don’t maintain Kodi ourselves. You would need to ask this to RPi developer.

Hello, how do I know which source is actual bookworm available Kodi provided from: debian, custom dietpi or RPI?

Depends on the device and image you are using, see

From what I gather from the script link, RPI4 64-bit bookworm “will only function with open source drivers (Fake KMS OpenGL desktop driver)” which is (I presume only) used by default on RPI OS. That I already knew, but how do I know where is the actual dietpi kodi package coming from?

On the other hand, according to Michael compiling kodi from popcornmix source had been an alternative on Bullseye until RPI OS provided it. Looking at Kodi building guide, it is quite difficult and time-consuming.

I wonder why does Kodi still need open source drivers instead of Broadcom binary ones. I’ve investigated and found that at least on RPI3B, “the VC4 GPU on the Pi is 32bit and when you use a 64 bit kernel, some structures are still 64bit values which breaks the interface”. This is from 2017. So, if i’m not wrong it seems there is no working Broadcom 64-bit driver leveraging opengl/vulkan acceleration for RPI4 yet, nor there will be. Am I correct?

We don’t manage or maintain these drivers. Not sure if we are able to answer your question. Maybe @MichaIng knows.

For Kodi, it might be the Debian package actually.

We do not compile/provide own Kodi packages but just install them from the RPi repo or Debian (on other hardware). We did ship own packages for a short time when Bullseye was newly released and RPi Ltd did not provide RPi-compatible (hardware-accelerated) packages for some months. Just check via:

apt policy kodi

to see which Kodi packages are available from where and which has priority.

Not “Fake KMS”, but “full KMS”, i.e. the true KMS video stack is required for those Kodi builds and enabled by default on RPi OS since Bullseye. “Fake KMS” is this vc4-fkms-v3d one which requires legacy closed-source libraries and provides some related APIs like DispmanX.

And yes, some of the legacy API libraries were not available for 64-bit in the first place, like MMAL. With Bookworm and the latest firmware packages we are about to migrate to, the whole legacy API/library stack has been completely removed anyway, and we will follow this and migrate software implementations to other backends or otherwise disable them.

1 Like

By curiosity, Why is mesa opengl/vulkan driver for wayland less performant than Kodi’s FullKMS on RPI not to need it in the first place?
Is it because of Broadcom not releasing and maintaining binary drivers on 64-bit?

Everyone, including RPi Ltd, aims to move to open source drivers. It is the explicit goal to stop using the Broadcom closed source driver blobs, and with Bookworm, a large step into this direction has been done.

1 Like