How to install KODI 18.7 on Bullseye?

Let me see if I have time tomorrow to do a test on PRi4B ARMv8

Not sure what changed but Kodi 19.1 is starting fine on my RPi4B ARMv8 Bullseye. :slight_smile:

May be of interest - there’s a thread on the Pi Foundation forum by Popcornmix about building Kodi (19.3) on Bullseye -

That is great news :smiley:!! The RPi Kodi repository is updated with a Bullseye branch:

It has a build script. Interesting is a build flag -DENABLE_VAAPI=OFF which seems to be the one we were looking for to mute the libva warnings on Kodi start.

Good notes also about rpivid-v4l2 device tree overlay for HEVC/H.265 hardware acceleration, cma-512 option for 4k video playback and that gpu_mem doesn’t need to be increased over the default value.

The question is whether it’s worth that we rebuild our ARMv6/7 packages for Bullseye with this, or whether we wait for it to be released via RPi package repository.

This sounds like good news. :slight_smile:

Does this mean CEC will now work? I formatted my card again and have only installed PiHole and Ubound currently I skipped Kodi due to CEC not working in Kodi on Bullseye.

That might already work now. libcec6 builds are available now:;O=D
The current Kodi package was compiled against libcec from Debian, but the same version 6.

After you mentioning that CEC might be working now I decided to install Kodi to test it out. I used dietpi-software command to do the install and rebooted after it was complete. I set Kodi to load at boot when I was prompted during the install. Kodi does not load though and I get an Error message and my RaspberryPi drops straight into root without needing to login it would seem?

The error message reads:
failed to open
ERROR: Unable to create GUI. Exiting

This is a clean RaspberryPi 3 install the only other software I had installed prior a day or two back was PiHole together with Unbound, both of these are working as expected.

Just a side note what would I need to change to allow Kodi to run at boot using the dietpi user? I guess this would stop it from dropping straight into root should it fail for any reason in future.

there is no benefit of running Kodi as user dietpi. If it fails, it will drop to CLI as well.

The topic we discussed above was to have Kodi running on RPi4 64bit. Can you share the Kodi version you use

Required Information

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname -a
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  • Kodi version | dpkg -l kodi

Hi Joulinar,

Thanks for replying and taking a look. Here is the information requested:

DietPi version:
G_LIVE_PATCH_STATUS[0]='not applied'

Distro version:
bullseye 0

Kernal version:
Linux RaspberryPi-3 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux

SBC model:
RPi 3 Model B+ (aarch64)

Kodi version:
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Architecture Description
ii  kodi           2:19.1+dfsg2-2 arm64        Open Source Home Theatre (executable binaries)

CEC should now work as the RPi Foundation has released iibcec6 on their repository.

ok I did some testing and indeed on RPi3B+ Kodi is not starting correctly. However I found a workaround. If you have Kodi installed already, just run following as user root

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-fkms-v3d

I guess we need to adjust our install options on RPi3B

No, the full KMS driver should definitely work, if the fake KMS driver does. So:

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-kms-v3d

should work. However, experimenting with our package isn’t necessary anymore as there is now one provided via RPi repository. Please try:

echo 'deb bullseye main untested' > /etc/apt/sources.list.d/raspi.list
apt update
apt install --reinstall --allow-downgrades kodi

it was a 64bit on RPi3B+, therefore Debian package was used if I’m not mistaken. During install of Kodi, we explicitly set

/boot/dietpi/func/dietpi-set_hardware rpi-opengl disable

and not the KMS driver

Joulinar and MichaIng

Thank you both for helping with this.

I first tried Joulinar’s suggestion of using the following command:

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-fkms-v3d

I can report that this worked and I was happy as Kodi was able to load on boot and CEC is now working too.

I also then went on to try the command posted in a follow up post by Michalng as shown here:

echo 'deb bullseye main untested' > /etc/apt/sources.list.d/raspi.list
apt update
apt install --reinstall --allow-downgrades kodi

I can report that after running those commands Kodi is working and so is CEC.

So both suggestions appear to resolve the issue of Kodi not loading.

Thank you both again for your time and effort. I can now finaly watch stuff again using Kodi. :slight_smile:

Well I guess there is good news and bad news.

The good news is Kodi now loads and CEC is working.

The bad news is that now playback of videos are choppy, these are the same video files that used to play back fine on Kodi for Buster.

Is it that Bullseye/Kodi is just too much for the Pi 3 now? Is this something that can and will get fixed in time? If so I will hold out for the fix and just do away with not using Kodi for now. If this is something that cannot be made to work as it was when using Buster than I will probably just restore my backup of Buster and stick with that.

Probably something to report to RPi Devs as we don’t build the Kodi package :thinking:

First of all, indeed we apply currently the wrong graphics driver on 64-bit Bullseye RPi images for RPi 2 and 3. Since Bullseye, the KMS driver needs to be used in every case. I just fixed that:
Although, now I wonder whether this works fine on 64-bit RPi 3 Buster :thinking:, where the older Debian package without GBM support is used. But actually the framebuffer devices are available even with KMS enabled, so it should, and X should run better with KMS in general.

Generally, for Kodi do not use the “fKMS” (fake KMS) driver but the “KMS” (full KMS) driver now. This might lead also to slightly better performance:

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-kms-v3d

Next, the new Bullseye kernel/firmware does not ship with the previous video decoder libraries anymore but uses libcamera and V4L2 libraries for decoding, depending on kernel modules which were previously used for the RPi camera only. So what could be tested is to remove the blacklists for the camera modules:

rm /etc/modprobe.d/dietpi-disable_rpi_camera.conf
modprobe bcm2835_codec bcm2835_v4l2 bcm2835_isp

On RPi 4 additionally for HEVC and 4k support:

G_CONFIG_INJECT 'dtoverlay=rpivid-v4l2' 'dtoverlay=rpivid-v4l2' /boot/config.txt
G_CONFIG_INJECT 'dtoverlay=vc4-kms-v3d' dtoverlay=vc4-kms-v3d,cma-512' /boot/config.txt

I tried applying the fix and changing the graphics driver using the command:

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-kms-v3d

After doing so I rebooted the Pi3.

I noticed that after changing the driver that the TV does not automatically turn itself on during a reboot of the Pi3 like it does when using the fake driver. I also had no sound with the videos I tried to play. Maybe the TV not turning itself on during reboot is connected in some way with the sound no longer working?

The video files still were lagging during playback. Nothing seemed to have changed other than the TV did not auto turn itself on and the sound was missing during playback as well.

I then removed the blacklists for the camera modules as suggested, and rebooted, but this did not seem to change anything. I still had no sound; TV would not auto turn on when rebooting Pi3 and video playback was still choppy.

Finally, I reverted back to the fake driver using the command:

/boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-fkms-v3d

Having done so the TV turn would turn itself on during a reboot of the Pi3 and I also had sound when playing videos although playback of them is still choppy as before.

Maybe trying to run PiHole, Unbound and Kodi on a Pi3 is too much? Though before I updated to Bullseye I was running, PiHole, cloudflared (manual install by myself which PiHole was using), Emby, Kodi.

Pi-hole and Unbound do not cause any relevant CPU usage, and zero GPU usage, so that doesn’t matter at all.

What do you mean by “TV does not automatically turn itself on”, does it not turn on at all, or only not “automatically” while you can trigger it somehow “manually”?

The issue with the sound with KMS is a good point. It adds additional HDMI audio devices for reasons I do not yet understand, hence the sound card index needs to be incremented. So in /etc/asound.conf you need to increment the card index by one in every occurrence, hence e.g. card 0 must become card 1. On RPi 4 it even needs to be incremented by 2 as two additional HDMI devices are created, one for each HDMI port.

Sorry my mistake, it just takes longer to wake up the TV when using the non fake driver (KMS). What I meant was that I leave the TV in standby and usually when I turn on or even reboot my Pi it will wake the TV up out of standby and switch to the HDMI input automatically. I was wrong though I just did not wait long enough, it does still do this as before just takes a little more time.

I tried incrementing the card 0 index by one as suggested but I still do not seem to have sound when using the KMS driver. I rebooted after making this adjustment and selecting the real KMS driver again.

Here is the contents of my /etc/asound.conf file with the adjustments I made:

pcm.!default {
        type hw
        card 1
        device 0

ctl.!default {
        type hw
        card 1