Kodi-Headless Server als Docker-Container

Auf der Suche nach einer Möglichkeit, die Medienstruktur meiner Kodi-Mediathek auch über DLNA verfügbar zu machen, habe ich bisher nur zwei verlässliche Möglichkeiten gefunden. Einmal per Serviio (kann die Kodi NFO-Dateien verwenden und bereitet die Struktur entsprechend auf) und natürlich über den in Kodi integrierten DLNA-Server. Im Gegensatz zu Serviio unterstützt der Kodi-DLNA-Server allerdings keine Foto-Kategorie, sondern nur Musik und Videos.


Das Hauptproblem mit normalen Kodi war, dass es typischerweise nur dann läuft, wenn man es interaktiv verwendet und damit ist der DLNA-Server auch nur dann verfügbar.

1. Kodi-Headless

Kodi kann allerdings auch Headless betrieben werden (ohne UI), aber die Einrichtung ist nicht trivial. Glücklicherweise gibt es seit einiger Zeit einen Docker-Container dafür. Alle Infos darüber findet man hier:

Das Ganze macht typischerweise nur Sinn, wenn man Kodi sowieso schon mit einer geteilten Datenbank verwendet (Einrichtung siehe auch Kodi für die Nutzung mit einer MySQL-Datenbank konfigurieren ). Die Fein-Konfiguration ist dann per Web-Interface möglich. Steuern kann man Kodi-Headless z.B. auch per YATSE, inklusive Casting auf andere Geräte.


Die Installation über die Container Station war zunächst recht einfach, allerdings war der DLNA-Server nicht im standardmäßigen NAT-Mode verwendbar (Web-Interface ging aber). Er wurde trotz aller erkennbar notwendigen manuellen Port-Mappings nicht von Clients erkannt. Deshalb habe ich den Container im Bridge-Mode konfiguriert und ihm eine eigene statische IP-Adresse aus meinem Heimnetzwerk gegeben. Damit funktioniert DLNA problemlos.


Wenn man die Konfiguration des Bridge-Mode aber nachträglich in der Container Station macht, geht diese Einstellung beim nächsten Container-Update (pull) verloren und muss erneut konfiguriert werden. Das ist natürlich nicht dauerhaft praktikabel, weshalb ich nach einer Möglichkeit per Docker-Compose Konfiguration gesucht habe und diese nun endlich auch gefunden habe. Leider konnte ich keine Dokumentation dazu finden und musste deshalb lange in den Tiefen des Internets suchen und bin schlussendlich auch in einer Diskussion im englischen QNAP-Forum fündig geworden.

2. Docker-Compose Schablone

Hier mal eine passende Schablone für Docker-Compose, die man direkt in der Container Station nutzen kann. Es müssen noch Benutzer (<user>), Passwort (<password>) und die IP (<ip-address1>) für die MySQL-DB eingetragen werden (ich nutze die auf dem NAS verfügbare MariaDB 10). Außerdem muss noch die IP-Adresse (<ip-address2>) für den DLNA-Server (Kodi) vergeben werden, die aus dem heimischen Netzwerk stammt, wo auch das NAS angemeldet ist. Achtung, diese muss außerhalb des DHCP-Bereichs liegen, der vom Router verwaltet wird!

Die Container Station erzeugt einen virtuellen Adapter im QTS Virtual-Switch und gibt diesem einen zufälligen Namen. Dieser Name kann per ssh docker network ls abgefragt werden und muss dann unter "networks" eingetragen werden.

3. Kodi Web-Interface Zugriff

Das Kodi Web-Interface ist nach dem Start des Containers über http://<ip-address2>:8080 zu erreichen. Dort kann man z.B. die Sprache einstellen, nach der sich auch die Sprache der DLNA-Knoten richtet.

4. NAT-Mode Hinweise

Wenn man es doch per NAT-Modus versuchen möchte, muss gegenüber der Originalkonfigurationsempfehlung des Containers der Web-UI-Server Port angepasst werden, da 8080 schon für die QTS-Administrationsseite verwendet wird. Dann muss man diesen Port auch in der advancedsettings.xml einsprechend eintragen:

Code: advancedsettings.xml
<services>
  <webserverport>8080</webserverport>
</services>

Außerdem müssen in der docker_compose.yml alle für DLNA notwendigen Ports gemapped werden.

5. Advancedsettings.xml

Insgesamt sieht meine advancedsettings.xml so aus (es sind noch ein paar weitere Dinge hinsichtlich Netzwerk konfiguriert):

6. Installation von Addons

Die Installation von Addons ist auf der GitHub- und auch auf der Docker-Hub-Seite beschrieben (nur per Kommandozeile, braucht man aber normalerweise nicht).