• Raspberry Pi 3
• Powered USB hub
• USB hard disk 1 Tb
• USB audio adapter
• Joystick controller
• LCD display 16×2 charaters

We started with a Raspbian 2017-11-29 lite, based on Debian Stretch. To have a minimal Kodi installation and support for the joystick, just install the following packages:

• kodi
• kodi-bin
• kodi-peripheral-joystick

Kodi will not start automatically at boot, just execute kodi-standalone from the command line.

NOTICE: Raspbian includes Kodi version 17.6 whereas Debian Stretch has Kodi 17.1, so beware of what packages you are installing and respect the right dependencies.

There are several recipes on the internet to start Kodi on boot; we searched one with the following features:

• Does not require xserver.xorg, as we have installed Raspbian Stretch Lite.
• Run Kodi as unprivileged user.
• Run as a service, do not use autologin and autostart tricks.
• Should be compliant with the underlying init system, which is systemd in Raspbian Stretch.
• Can perform reboot and poweroff from Kodi menu.

So we want to execute kodi-standalone as kodi user, create that user first and assign him to the required groups:

adduser --disabled-password --gecos "User to run Kodi Media Center" kodi
adduser kodi audio
adduser kodi video
adduser kodi plugdev
adduser kodi input

Then we created a systemd unit file /etc/systemd/system/kodi.service to start Kodi as a service. Please do not use an old fashioned sysvinit start/stop script (e.g. /etc/init.d/kodi), because the new systemd can use it only in compatibility mode.

[Unit]
Description = Kodi Media Center

# if you don't need the MySQL DB backend, this should be sufficient
After = systemd-user-sessions.service network.target sound.target

# if you need the MySQL DB backend, use this block instead of the previous
# After = systemd-user-sessions.service network.target sound.target mysql.service
# Wants = mysql.service

[Service]
User = kodi
Group = kodi
Type = simple
ExecStart = /usr/bin/kodi-standalone
Restart = always
RestartSec = 15

[Install]
WantedBy = multi-user.target

To actually enable and start the service, run:

systemctl daemon-reload
systemctl enable kodi.service
systemctl start kodi.service

Now we have to solve a problem: the unprivileged Kodi user cannot perform reboot and poweroff actions: as you can se the exit menu of Kodi show only the Exit item. We need two piece of software: policykit-1 and consolekit. The first package contains the framework which handles the authorizations, accordinf to the Freedesktop.org guidelines. The second one is required to allow some actions even if the running process does not have a console terminal allocated to it.

apt-get install policykit-1 consolekit

Finally we create two files. The first one /etc/polkit-1/localauthority/50-local.d/50-kodi.pkla allows the Kodi user to execute some privileged actions:

[Actions for kodi user]
Identity=unix-group:kodi
Action=Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*
ResultActive=yes
ResultAny=yes
ResultInactive=no

The second one /etc/polkit-1/localauthority/50-local.d/power.pkla, allows all the users belonging to the plugdev group to perform what? :

[Allow consolekit]
Identity=unix-group:plugdev
Action=org.freedesktop.consolekit*
ResultAny=yes
ResultInactive=no
ResultActive=yes

[Allow login1]
Identity=unix-group:plugdev
Action=org.freedesktop.login1*
ResultAny=yes
ResultInactive=no
ResultActive=yes

[Allow Upower]
Identity=unix-group:plugdev
Action=org.freedesktop.upower*
ResultAny=yes
ResultInactive=no
ResultActive=yes

Missing the consolekit part of the recipe - in our experienece - resulted into the kodi user to be authorized to the power actions only if he was logged into a text conole (actually logging-in as root, executing su to kodi and launching kodi-standalone). To gain the power privileges even if starting kodi-standalone from a systemd service or from a remote login, you need the consolekit recipe above.

The first attempt was an Amazon Basics USB 3.0 4 ports hub. Unfortunately it is based on the VIA Labs chips, which seems to have a bug, so it is uncompatibile with the Raspberry Pi.

The device is listed on the USB bus:

Bus 001 Device 005: ID 2109:2811 VIA Labs, Inc. Hub

but when you connect even a simple mouse, you get plenty of errors, and the device does not work:

usb 1-1.4.1: new low-speed USB device number 6 using dwc_otg
usb 1-1.4.1: device descriptor read/64, error -71
usb 1-1.4.1: device descriptor read/64, error -71
usb 1-1.4.1: new low-speed USB device number 7 using dwc_otg
usb 1-1.4.1: device descriptor read/64, error -71
usb 1-1.4.1: device descriptor read/64, error -71
usb 1-1.4.1: new low-speed USB device number 8 using dwc_otg
usb 1-1.4.1: device not accepting address 8, error -71
usb 1-1.4.1: new low-speed USB device number 9 using dwc_otg
usb 1-1.4.1: device not accepting address 9, error -71
usb 1-1.4-port1: unable to enumerate USB device

I tried several workarounds: leaving the hub unpowered, attaching an USB 3.0 external hard disk, adding the option dwc_otg.speed=1 into /boot/cmdline.txt. None of that gave a minimal benefit. I returned the hub back to Amazon.

Here are some web references:

• USB 3.0 hub fails to pass through USB 2.0 devices (ID 2109:3431)
• AmazonBasics 4 Port USB 3.0 Hub not working
• documentation > hardware > raspberrypi > usb
• RPi Powered USB Hubs