After a fresh installation of RaspiOS 13 Trixie and Kodi 21.1 package, I experienced an high CPU load (load average at about 2) with an idle system, where the Kodi process was the first on top.

This were a significant worsening over the previous installation, where the load average for the idle system was lower than 0.1.

Digging through the log files I found that the load increase corresponded to the appearance of the following kernel messages:

kernel: cec-vc4-hdmi-0: message 10 timed out

Indeed it seems that the LG 32LG5010 TV connected to the HDMI cable causes that timeout when it goes to standby mode. It must also be said that the CEC (remote control passthrough from TV to Kodi) do not work in this hardware combination, so I disabled the CEC controller in Kodi and solved the high CPU load.

To disable the controller I stopped the Kodi process and changed the $HOME/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml file:

<settings>
    <setting id="activate_source" value="0"/>
    <setting id="enabled" value="0"/>
    ...
</settings>

I have an external 3.5 inches 4 Tb hard disk connected to the Pi 4 USB port using a X835 board. A large data partition (/dev/sda3) is mounted at bootstrap because there is an entry into /etc/fstab.

The Kodi process uses the udisks2 subsystem to automount connected devices. Since there is also a /dev/sda2 partition on the disk, this is automatically mounted as soon as the Kodi process is started. From the journalctl log you can see:

systemd[1]: Starting udisks2.service - Disk Manager...
udisksd[1202]: udisks daemon version 2.10.1 starting
dbus-daemon[694]: [system] Successfully activated service 'org.freedesktop.UDisks2'
udisksd[1202]: Mounted /dev/sda2 at /media/kodi/9f259ae2-1de9-... on behalf of uid 1001

I haven't found a way to prevent automounting of just the /dev/sda3 partition using the udisks2 configuration. The only truly horrible way was to set a wrong mount parameter for that partition, causing it to fail. I.e. it is possibile to create the file /etc/udisks2/mount_options.conf with a bad mount option like this:

This does not work:

[/dev/disk/by-uuid/9f259ae2-1de9-...]
automount=false

It was impossibile to disable automount via the dbus subsystem too. Creating a file /etc/udev/rules.d/99-udisks2-noauto.rules with the following content has no effects:

This does not work:

ENV{ID_FS_UUID}=="9f259ae2-1de9-...", ENV{UDISKS_AUTO}="0"

ENV{ID_FS_UUID}=="9f259ae2-1de9-...", ENV{UDISKS_IGNORE}="1"

To reload the udev settings I used:

udevadm control --reload
udevadm trigger

After all, because I don't need automount of connected devices, I removed the udisks2 package at all.

In a previous installation (RaspiOS 11 Bullseye) I managed to let the hard disk to spin-down after some time of inactivity. The same configuration did not work on this new installation; it turned out that the culprit was the udisks2 subsytem.

Actually the udisks can set APM options for using ATA commands (see man 8 udisks), but I had no time to investigate. Simply removing the udisks2 package solved the problem and the spin-down of the disk worked as in the previous installation.

The default Raspberry Pi OS installation uses NetworkManager to manage network connections. That framework is very convenient for a desktop system, but for a Kodi media center I prefer the dhcpcd package. To remove the NetworkManager package you need to remove also the raspberrypi-net-mods one:

apt install dhcpcd
dpkg --purge network-manager raspberrypi-net-mods

The dhcpcd daemon correctly detects the WiFi interface of the Raspberry Pi 4 (wlan0), it expects that the WiFi protocol is managed by the systemd wpa_supplicant.service.

The problem of having two instances of the wpa_supplicant daemon (seen on the Raspberry Pi OS based on Debian 10 Buster), seems to be solved.

The default RaspiOS 13 installation relies on systemd-journald.service (provided by the systemd package) for system logging; the rsyslog package is not installed at all. The default configuration places the journal on the volatile memory (see /usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf), preserving disk space and avoiding SD card writes.

In previous Raspberry Pi installations I used to remove rsyslog in favour of busybox-syslogd to have logs in volatile memory (readable with logread), but now I will stay with this more modern configuration.

If the Raspberry Pi boots while the HDMI cable is disconnected, no video signal is produced on the port. In older versions of Raspberry Pi OS there were options to be declared in the /boot/config.txt file, to force the HDMI output and even the video mode. These options are listed here, but beware that they not longer work!

# Obsolete options for /boot/config.txt
# They no longer work with Raspberry Pi OS 13.
# Force HDMI even if unplugged or powered off
hdmi_force_hotplug=1
# Normal HDMI mode (Sound will be sent if supported and enabled)
hdmi_drive=2
# Select DMT (monitor) mode group, mode = 39 (1360x768 @ 60Hz)
hdmi_group:0=2
hdmi_mode:0=39

On the new Raspberry Pi OS based on Debian 13 Trixie the boot configuration files were moved into /boot/firmware/:

• /boot/firmware/cmdline.txt
• /boot/firmware/config.txt

Older options shown above are ignored, but you can pass some parameters to the kernel command line, appending them to the line contained into /boot/firmware/cmdline.txt.

First of all verify the output of the kmsprint command when the display is actually connected and the resolution is correctly negotiated via the EDID protocol:

Connector 0 (33) HDMI-A-1 (connected)
  Encoder 0 (32) TMDS
    Crtc 3 (100) 1360x768@59.80 84.750 1360/72/136/208/- 768/3/5/22/+ 60 (59.80) P|D 
      Plane 6 (125) fb-id: 721 (crtcs: 1 2 3 4 5) 0,0 1360x768 -> 0,0 1360x768
              (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24
              YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12
              AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 721 1360x768 XR30
Connector 1 (42) HDMI-A-2 (disconnected)
  Encoder 1 (41) TMDS

Append the following option to force the HDMI output, pretending that the display is connected:

vc4.force_hotplug=1

In this way the Raspberry Pi will report HDMI-A-1 (connected) even if not. In my case the resolution applied were 1024×768@60.00, which is under-optimal and a bit ugly on my display.

To force the desired video resolution I also appended the following parameter to the cmdline.txt:

video=HDMI-A-1:1360x768@59.80

You can also simulate that your monitor is connected to the Raspberry Pi and providing EDID data, just copy the EDID data when your TV or monitor is actually attached to the HDMI port:

cat /sys/class/drm/card1-HDMI-A-1/edid  > /lib/firmware/32LG5010-edid.bin

The file must be stored into the /lib/firmware/ directory, I named it upon the screen model (a 32 inches LG TV). To use it, just append the following option to cmdline.txt (you can omit the video option, because the optimal resolution will bee choosen from the EDID data):

drm.edid_firmware=HDMI-A-1:32LG5010-edid.bin

See also:

• Bullseye equivalent for hdmi_force_hotplug=1?
• hdmi_drive=2 alternative for KMS