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.

• Remove NetwokManager (and raspberrypi-net-mods due dependency)
• Install Dhcpcd
• Who launches wpa_supplicant on wlan0?

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

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.