How to install KODI 18.7 on Bullseye?

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

ISquishWorms
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
reboot

MichaIng
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
reboot

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

echo 'deb https://archive.raspberrypi.org/debian/ bullseye main untested' > /etc/apt/sources.list.d/raspi.list
apt update
apt install --reinstall --allow-downgrades kodi

MichaIng
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
reboot

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 https://archive.raspberrypi.org/debian/ 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: https://github.com/MichaIng/DietPi/commit/1141162
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
}

Can you check the output of the following command to list all sound devices and their index:

aplay -l

Ah according to that command that you provided I do not have a card 1. I have a card 0 and a card 2.

**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 2: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I will try again later but this time I will set it to card 2 and will report back. I have just remembered I do have a cheap USB Mic plugged into it, not sure why it lists Headphones though as I do not have any of them connected.

Is there a way to check that I do infact have the correct version from that raspberry untested repo as at the top left Kodi’s title reads: “Kodi from debian”. I was wondering if that is correct? I am just not convinced that it is using the correct repo as on the Raspberry Pi forum in the Build Kodi topic users are reporting that the CEC is not working unless they build it themselves, yet my CEC is working?

It is fixed, including smooth playing of movies with sound and CEC.

Thank you both so much for all the help and your patience. :smiley: <3

Here are the steps I took that seemed to fix it.

  1. Uninstalled Kodi.
  2. Rebooted
  3. echo ‘deb https://archive.raspberrypi.org/debian/ bullseye main untested’ > /etc/apt/sources.list.d/raspi.list
  4. apt update
  5. apt install --reinstall --allow-downgrades kodi (this time it def used the untested repo, don’t think it did when I tried previously)
  6. /boot/dietpi/func/dietpi-set_hardware rpi-opengl vc4-kms-v3d (think this was already set to KMS as I had left it from testing earlier)
  7. nano /etc/asound.conf (changed all instanaces of card 0 to card 2. I guess this may need to be a diff number for other users)
  8. dietpi-config → AutoStart Options → Kodi
  9. Rebooted
  10. Kodi Settings → System → Audio → Audio output device → vc4-hdmi, SAM SAMSANG on HDMI

Played video was not choppy, had sound and CEC is working. :sunglasses:

Blacklists for the camera modules were removed in previous testing, not sure what impact if any this had on the outcome of the above procedure.

Maybe I did not need to change the file /etc/asound.conf and could have just changed the Audio output device within Kodi I am not sure if this step is required.

Off to watch some videos, thanks again…

Great that it works now.

I’m a bit confused about KMS and sound card indices now. In the past at least the vc4hdmi sound card(s) appear with lowest index and the regular 3.5mm hack/HDMI cards with higher index. Obviously this has changed, which is good as then the index doesn’t need to be adjusted anymore, only based on whether KMS is enabled or not.

But you say now using card 0 for 3.5mm jack audio does not work? Or as you should get HDMI audio now with card 2, were you expecting HDMI audio before?

Could you test the following:

/boot/dietpi/func/dietpi-set_hardware soundcard rpi-bcm2835-auto
sed -i 's/card 1/card 0/' /etc/asound.conf
reboot
# after reboot
aplay -l

And if card 1 is not available or card 0 is not the regular HDMI device (not “vc4hdmi”, but “HDMI”):

/boot/dietpi/func/dietpi-set_hardware soundcard rpi-bcm2835-hdmi
sed -i 's/card 1/card 0/' /etc/asound.conf
reboot
# after reboot
aplay -l

The question is whether KMS somehow breaks regular audio output, or whether it at least forcefully disabled the regular HDMI sound device. Interesting is that it is index 2 even that index 1 is not set.

Ah and now I see the audio device setting in Kodi. Please try to leave this at “default” to not force usage of this “vc4hdmi” audio device.

The reason I changed the audio device setting in Kodi is because I still had no sound until I did this.

Here are the results of the commands you asked me to try:

root@RaspberryPi-3:/home/dietpi# /boot/dietpi/func/dietpi-set_hardware soundcard rpi-bcm2835-auto

 DietPi-Set_hardware
─────────────────────────────────────────────────────
 Mode: soundcard (rpi-bcm2835-auto)

[ INFO ] DietPi-Set_hardware | Checking for required APT packages: alsa-utils
[  OK  ] DietPi-Set_hardware | All required APT packages are already installed.
[ INFO ] DietPi-Set_hardware | Resetting all sound card settings...
[  OK  ] DietPi-Set_hardware | rm /etc/asound.conf
[  OK  ] DietPi-Set_hardware | rm /var/lib/alsa/asound.state
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -2
Found hardware: "USB-Audio" "USB Mixer" "USB8086:0808" "" ""
Hardware is initialized using a generic method
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2
Found hardware: "vc4-hdmi" "" "" "" ""
Hardware is initialized using a generic method
[  OK  ] DietPi-Set_hardware | sed -Ei s/^[[:blank:]]*(hdmi_drive(:[01])?=.*$)/#\1/ /boot/config.txt
[  OK  ] DietPi-Set_hardware | sed -Ei /^[[:blank:]]*dtoverlay=dietpi-disable_(hdmi_audio|headphones)/d /boot/config.txt
[  OK  ] DietPi-Set_hardware | Setting in /boot/config.txt adjusted: dtparam=audio=off
[ INFO ] DietPi-Set_hardware | Applying new sound card settings...
[  OK  ] DietPi-Set_hardware | Desired setting in /boot/dietpi.txt was already set: CONFIG_SOUNDCARD=rpi-bcm2835-auto
[  OK  ] DietPi-Set_hardware | Setting in /boot/config.txt adjusted: dtparam=audio=on
[  OK  ] DietPi-Set_hardware | alsactl -g store
[  OK  ] soundcard rpi-bcm2835-auto | Completed
root@RaspberryPi-3:/home/dietpi# sed -i 's/card 1/card 0/' /etc/asound.conf
root@RaspberryPi-3:/home/dietpi# reboot
root@RaspberryPi-3:/home/dietpi# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 2: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

As card 1 was not available and card 0 was not the regular HDMI device I went on to try the other commands. Here are the results of those commands:

root@RaspberryPi-3:/home/dietpi# /boot/dietpi/func/dietpi-set_hardware soundcard rpi-bcm2835-hdmi

 DietPi-Set_hardware
─────────────────────────────────────────────────────
 Mode: soundcard (rpi-bcm2835-hdmi)

[ INFO ] DietPi-Set_hardware | Checking for required APT packages: alsa-utils
[  OK  ] DietPi-Set_hardware | All required APT packages are already installed.
[ INFO ] DietPi-Set_hardware | Resetting all sound card settings...
[  OK  ] DietPi-Set_hardware | rm /etc/asound.conf
[  OK  ] DietPi-Set_hardware | rm /var/lib/alsa/asound.state
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -2
Found hardware: "USB-Audio" "USB Mixer" "USB8086:0808" "" ""
Hardware is initialized using a generic method
alsa-lib parser.c:2179:(load_toplevel_config) Unable to find the top-level configuration file '/usr/share/alsa/ucm2/ucm.conf'.
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2
Found hardware: "vc4-hdmi" "" "" "" ""
Hardware is initialized using a generic method
[  OK  ] DietPi-Set_hardware | sed -Ei s/^[[:blank:]]*(hdmi_drive(:[01])?=.*$)/#\1/ /boot/config.txt
[  OK  ] DietPi-Set_hardware | sed -Ei /^[[:blank:]]*dtoverlay=dietpi-disable_(hdmi_audio|headphones)/d /boot/config.txt
[  OK  ] DietPi-Set_hardware | Setting in /boot/config.txt adjusted: dtparam=audio=off
[ INFO ] DietPi-Set_hardware | Applying new sound card settings...
[  OK  ] DietPi-Set_hardware | Setting in /boot/dietpi.txt adjusted: CONFIG_SOUNDCARD=rpi-bcm2835-hdmi
[  OK  ] DietPi-Set_hardware | Setting in /boot/config.txt adjusted: dtparam=audio=on
[  OK  ] DietPi-Set_hardware | Compiling device tree overlay: /boot/overlays/dietpi-disable_headphones.dtbo
[  OK  ] DietPi-Set_hardware | Added setting dtoverlay=dietpi-disable_headphones to end of file /boot/config.txt
[  OK  ] DietPi-Set_hardware | Comment in /boot/config.txt converted to setting: hdmi_drive=2
[  OK  ] DietPi-Set_hardware | alsactl -g store
[  OK  ] soundcard rpi-bcm2835-hdmi | Completed
root@RaspberryPi-3:/home/dietpi# sed -i 's/card 1/card 0/' /etc/asound.conf
root@RaspberryPi-3:/home/dietpi# reboot
root@RaspberryPi-3:/home/dietpi# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

After rebooting I went back into Kodi and changed the audio output device back to: Default(vc4-hdmi MAI PCM i2s-hifi-0)()
I still have sound having changed it back to Default although it is quieter than when I had it set to: vc4-hdmi, SAM SAMSANG on HDMI

Hope this is of some help and what you were after, I do have a USB Mic plugged into the Pi this is just a very small mic though and has no headphones. I am not sure if that is messing with the card index.

Very strange, so indeed the full KMS driver seems to completely replace the previous HDMI sound device with its own one now. That was different before. And it is card 2 even that card 1 is then unused, but when headphones are disabled as well (second test with HDMI only enabled), it is card 0… Puhh difficult logic. I’ll also run some tests to verify that it’s the same on all RPi models.

Ah I forgot the overlay parameters to disable KMS HDMI, though not sure whether this leaves/makes the general HDMI sound device available:

G_CONFIG_INJECT 'dtoverlay=vc4-kms-v3d' 'dtoverlay=vc4-kms-v3d,noaudio' /boot/config.txt
reboot
aplay -l

Probably, since it is a “HDMI/HVS/V3D driver”, it is simply required to use it’s own HDMI audio device than while the usual one works only without full KMS driver :thinking:.

Here is the result of running those commands:

root@RaspberryPi-3:/home/dietpi# G_CONFIG_INJECT 'dtoverlay=vc4-kms-v3d' 'dtoverlay=vc4-kms-v3d,noaudio' /boot/config.txt
[  OK  ] G_CONFIG_INJECT | Setting in /boot/config.txt adjusted: dtoverlay=vc4-kms-v3d,noaudio

root@RaspberryPi-3:/home/dietpi# reboot

root@RaspberryPi-3:/home/dietpi# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
  Subdevices: 7/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7

After running the above commands I see the Pi start booting some text flashes on the TV screen as it boots. Then the display goes blank and the TV says No HDMI Signal.

I can log into my Pi using SSH though.
I manually edited the /boot/config.txt and removed the noaudio and now it boots again into Kodi.

Within Kodi audio output device settings I have the folllowing listed (I am using the Default as suggested).

  1. Default (vc4-hdmi MAI PCM i2s-hifi-0) ()
  2. vc4-hdmi (),MAI PCM i2s-hifi-0
  3. vc4-hdmi (vc4hdmi), MAI PCM i2s-hifi-0
  4. vc4-hdmi (vc4hdmi), SAM SAMSUNG on HDMI

The official legit noaudio parameter breaks KMS? A pity… It did restore the original HDMI sound device, so would be been a good solution. Probably a bug that needs to be resolved firmware wise.

When I used: G_CONFIG_INJECT ‘dtoverlay=vc4-kms-v3d’ ‘dtoverlay=vc4-kms-v3d,noaudio’ /boot/config.txt and rebooted the Pi3 flashed some text on the screen looked like it was trying to reboot as normal. This text vanished and the HDMI then dropped and I had no signal to the TV. I was unable to connect using SSH when I tried I would get SSH connection refused. Only after turning the Pi3 off for 30 seconds and then back on was I able to connect using SSH, I still had no signal from the HDMI though that got dropped during boot.

I think it might very well be a firmware bug. As with that noaduio command I could not always connect back to the Pi3 simply by rebooting I would have to turn if off and on again to be able to connect via SSH. It is like something is crashing during boot before it fires up the SSH server. My guess is it crashes at the point that the HDMI fails during boot. I would then have to turn on and off the Pi3 even though the same thing happens with HDMI in that the signal drops I was able to get on using SSH. So I guess it at least manages to load the SSH server if the Pi is not simply rebooted but turned off and then back on. Hope that makes some sense I tried to explain it the best I can.

To fix it I simply removed the noaduio manually using nano from the /boot/config.txt after doing that it would boot normally.

Maybe it could also be a bug with Kodi? As this will be trying to load up on boot. Perhaps it has issues loading if noaduio has been set for some reason. If it is Kodi crashing though on boot then I do not understand why the SSH server did not seem to be running and I got a connection refused when I tried to connect. Is that loaded up before Kodi trys to load? Maybe if it is Kodi crashing on boot it takes down the Pi or some other services with it so the SSH server gets killed off with it? I am just guessing now. Maybe it is because the audio output device is set to Default within Kodi so when the device is disabled it just hangs or crashes as it can’t find it? As Kodi loads on boot it could be Kodi and not a firmware bug I guess dunno.