MariaDB für Kodi, Howto

Hi.

Nachdem immer wieder Probleme mit der gemeinsamen Datenbank für Kodi auftauchen und ich das absolut gar nicht verstehen kann, dachte ich, ich schreibe mal ein kurzes "HowTo" wie ich das seit (denke ich) mindestens Kodi 16 so mache und noch nie Probleme damit hatte.

Als Voraussetzung braucht man natürlich einen Datenbank Server. Früher MySQL, heute eher die Open Source Variante davon, MariaDB, die vollständig kompatibel ist. Und auch eine Hardware, auf der diese Software läuft. Das kann ein NAS sein, ein RaspberryPi oder sogar eine Android Box oder zur Not sogar ein Smartphone, völlig egal. MariaDB Server gibt es buchstäblich für jedes System. Idealerweise läuft dieses Gerät 24/7. Sonst muss es auf jeden Fall vor dem ersten Kodi Klienten gestartet sein und muss laufen, bis der letzte Kodi Klient abgeschaltet ist. In sofern macht 24/7 durchaus Sinn. Man hat also die passende Hardware laufen und dort eine MariaDB Instanz installiert. Irgendwelche besonderen Einstellungen muss man nicht vornehmen. Man braucht nur einen User, der Datenbanken anlegen, ändern und löschen kann. Das kann man per MySQL CLI Befehlen direkt auf dem Gerät machen. Oder man verwendet ein Verwaltungstool. Am bekanntesten ist wohl PHPMyAdmin. Ich persönlich bevorzuge aber eine APP Lösung, keine Web Lösung. Für PHPMyAdmin braucht man einen vollwertigen Webserver. Ist der sowieso vorhanden, spricht nichts gegen PHPMyAdmin. Müsste man den aber extra dafür einrichten, ist das übers Ziel hinausgeschossen. Grade bei eher stromsparenden und deswegen meist schwachen Geräten würde ich mir diese zusätzlich Last nicht unbedingt antun wollen. Man kann dasselbe nämlich auch mit so etwas wie HeidiSQL tun. HeidiSQL ist eine OpenSource Standalone App für Windows. Bei Linux oder Mac gibt es sicher vergleichbares oder man muss eben doch einen Webserver mit PHP aufsetzen.

Egal wie, wir haben nun einen "mächtigen" Datenbank- User angelegt, der Datenbanken und Tabellen anlegen, verändern und löschen darf. Nennen wir ihn der Einfachheit halber mal "kodi". Dieser User hat natürlich ein Passwort bekommen. Nennen wir es der Einfachheit halber mal "kodi". Natürlich könnt ihr hier nehmen, was ihr mögt. Ihr müsst euch die User/Pass Kombination nur gut merken, denn die wird noch gebraucht.

Damit ist die größte Hürde schon überwunden. Der "Rest" wird jetzt in Kodi, genauer in einer einzigen Kodi Instanz erledigt. Bei mir ist das mein Desktop- System, da man hier einfach am besten editieren, kopieren,... kann. Mit Fernbedienung auf einer TV Box macht sich das einfach nicht so gut.

Zunächst müssen wir Kodi mitteilen, das es ab jetzt nicht mehr die lokalen SQLite Datenbanken verwenden soll, sondern die zentrale MariaDB Datenbank. Das passiert (leider immer noch) in der Datei "advancedsettings.xml". Diese Datei ist bei einer neuen Kodi Installation nicht vorhanden. Deswegen müssen wir zuerst mal eine entsprechende Datei erzeugen. Das geht mit jedem Text Editor auf jedem System. Die Datei wird dann ins Kodi Userdata Verzeichnis kopiert. Was man alles mit der "advancedsettings.xml" anstellen kann, kann man im Wiki nachlesen. Für diesen Zweck brauchen wir nur die "Datenbank- Abteilung". So kann diese Datei z.B. "von Innen" aussehen.

<advancedsettings>

<videodatabase>
<type>mysql</type>
<host>192.168.1.24</host>
<port>3306</port>
<user>kodi</user>
<pass>kodi</pass>
</videodatabase>

<musicdatabase>
<type>mysql</type>
<host>192.168.1.24</host>
<port>3306</port>
<user>kodi</user>
<pass>kodi</pass>
</musicdatabase>

</advancedsettings>

Man sieht, es gibt zwei Einträge, videodatabase und musicdatabase. Dazwischen sind dann die Zugangsdaten eingefügt. User und Pass sind dieselben, die wir vorher in der MariaDB angelegt haben. Der Type ist immer MySQL, da auch MariaDB eine MySQl Datenbank ist. Der Port ist standardmäßig 3306. Theoretisch kann man den beim Einrichten von MariaDB auch ändern, sollte man ohne Not aber nicht tun. Falls man einen anderen Port verwendet, muss man das hier entsprechend anpassen.

Der "schwierigste" Part ist der host Bereich. Mit Abstand am besten ist es, wenn man hier eine feste IP Adresse (im Beispiel 192.168.1.24) zur Verfügung hat. Generell sollte jede Art von Server im Netz eine fest zugewiesene IP Adresse haben und darüber angesprochen werden. Das vereinfach das "Netzwerken" ungemein. Die IP Adressen kann man fest im Gerät zuordnen oder fast immer auch im Router, ohne die Gerätekonfiguration ändern zu müssen. So sieht das dann z.B. in der Fritzbox mit FritzOS 8 aus. Vergleichbare Einstellungen gibt es bei fast jedem Router. So bekommt der Server stets dieselbe feste IP Adresse zugewiesen, ohne das man am Gerät selbst irgendwas konfigurieren muss. Ich weise allen Geräten, die regelmäßig im Heimnetz sind, feste Adressen zu, nicht nur den "Servern". Damit läuft das Netz einfacher, stabiler und schneller.

Geht das aus irgendwelchen Gründen nicht, kann man hier auch den Hostnamen (im Beispiel "uhura") verwenden. Damit kommen aber nicht alle Geräte/Betriebssysteme zurecht.

Nun speichern wir unsere "advancedsettings.xml" Datei, idealerweise auf dem NAS in einem extra Ordner (bei mir heißt er "Kodi-Files"). Von dort wird die "advancedsettings.xml" nun nach allen Kodi Klienten jeweils ins "userdata" Verzeichnis kopiert. Ab dann verwendet Kodi die MariaDB Datenbank, nicht mehr die lokalen SQLite Datenbanken.

Die "neue" Datenbank ist ja noch leer und muss zunächst mal gefüllt werden. Dazu starten wir Kodi, irgendwo. Ich mache sowas immer auf meinem Desktop, aus denselben Gründen wie das Erstellen der "advancedsettings.xml"... Könnt ihr aber machen, wo und wie ihr wollt, so lange die "advancedsettings.xml" gleich ist. Um Medien zu Kodi hinzuzufügen, benötigt man Medienquellen. Diese legt man ganz normal wie sonst auch in Kodi an. Wichtig ist nur, das man soweit möglich über (fest eingestellte) IP- Adressen geht, nicht über Hostnamen. Zwingend vermeiden muss man allerdings lokale "Freigaben", also sowas wie "D:\Filme". Das funktioniert nicht. Statt "D:\Filme" muss man also "//192.168.1.xxx/D/Filme" verwenden, wie eben der Netzwerkpfad zu dem Ordner lautet.

Nun beginnt Kodi, die Medien aus dem Ordner in die Datenbank einzulesen. Das läuft exakt genau wie immer ab. Man kann beliebig viele Quellen anlegen mit verschiedenen Typen (Serien, Filme, Musik, Musikvideos, nicht kategorisierte Videos, Bilder,....) wobei Bilder nicht in die Kodi Datenbank eingelesen werden. Trotzdem sollte man sie auch jetzt schon einpflegen, denn so spart man sich das bei weiteren Kodi Klienten. Sind alle Datenquellen angelegt und alle Medien eingelesen, beendet man Kodi wieder. Nun sind im "Userdata" Verzeichnis auch folgende XML Dateien zu finden:

mediasources.xml

passwords.xml

sources.xml

Es gibt hier noch mehr xml Dateien, aber nur diese drei sind für uns jetzt von Bedeutung. Diese drei Dateien kopiert man zu der advancedsettings.xml aufs NAS (oder wo auch immer man die Datei lagert, könnte ja auch ein USB Stick sein). Wenn man nun alle 4 Dateien in das Kodi userdata Verzeichnis einer beliebigen Kodi Installation (derselben Hauptversion, also nur Kodi 21.x Installationen oder nur Kodi 20.x Installationen oder nur Kodi 22.x Installationen,...) kopiert, ist dort die Datenbank und alle Medienquellen fertig eingerichtet und kann sofort verwendet werden. Das verwendete System (OS) spielt dabei überhaupt keine Rolle. Bei mir gibt es Kodi Klienten unter Windows, Android, LibreElec und CoreElec, x86, x86-64, ARM und ARM64 CPU. Spielt keinerlei Rolle. Die Daten (Gesehen Zustände usw.) werden dabei direkt synchron gehalten, ohne das man irgendwas weiteres tun oder beachten muss. Neue Medien kann man prinzipiell auf jedem der angeschlossenen Systeme einpflegen und sie stehen sofort auf allen angeschlossenen Systemen zur Verfügung. Ich selbst mache das immer vom Desktop aus, da ich von hier sowieso die Medien in die Quellen verschiebe, also ohnehin grade dran sitze. Das ist aber reine Geschmackssache.

Wenn wir jetzt die Kodi Hauptversion ändern (in der Regel "vergrößern"), dann müssen wir das zunächst auf einem Gerät machen. Startet man dort Kodi nach dem Upgrade, wird die Datenbank migriert. Das ist exakt so, wie "früher" mit den lokalen Datenbanken auch. Ist die Migration abgeschlossen, sind alle Medien in der neuen Datenbank vorhanden. Sobald man nun auf einem anderen Gerät die neue Kodi Hauptversion startet, ist die Datenbank bereits migriert und man kann nahtlos weiter machen. Bis dahin steht ja immer noch die "alte" Datenbank zur Verfügung, die man parallel weiter nutzen kann. Was nicht funktioniert ist das Synchronisieren der Gesehen Zustände. Die werden beim Migrieren der Datenbank auf dem ersten Kodi übernommen. Schaut man danach noch etwas mit einem "alten" Kodi, so wird das im "neuen" Kodi nicht automatisch als Gesehen gekennzeichnet. Man sollte also nicht all zu viel Zeit mit der Migration "verschwenden" bzw. ein externes Addon wie WatchedList zum Angleichen einsetzen. Bei wenigen Medien lässt sich das ganz gut auch komplett von Hand regeln. Beim Upgraden innerhalb der gleichen Hauptversion ist das in aller Regel kein Problem, denn die Datenbank ändert sich nicht (entscheidend) innerhalb derselben Hauptversion. Man kann also problemlos von Kodi 21.0 nach Kodi 21.1 wechseln und trotzdem auch längerfristig auf einem anderen Gerät weiterhin Kodi 21.0 verwenden. Bei Nightlies kann es vorkommen, das die DB sich "zwischendrin" ändert. Bei Stable Versionen aber nicht. Das ist halt das Risiko, wenn man Alpha oder Beta Versionen verwendet.

Hi.

Ein kleiner Nachtrag. Wenn man später neue Medienquellen hinzufügen oder bereits vorhandene Quellen entfernen will/muss, so macht man auch das (incl. einer eventuellen Datenbankbereinigung) auf einem einzigen Kodi Klienten. Welcher Klient ist wieder egal. Wenn diese Änderungen fertig sind, muss man die drei "anderen" xml Dateien (mediasources.xml, passwords.xml, sources.xml), die bei dieser Aktion von Kodi geändert wurden, erneut umkopieren, also von dem Kodi, an dem man die Änderungen durchgeführt hat aufs NAS (USB Stick oder wo auch immer) und anschließend auf alle anderen Kodi Systeme. Dabei die schon vorhandenen Dateien überschreiben. So werden auch Änderungen an den Medienquellen einheitlich erledigt. Die advancedsettings.xml muss dazu übrigens nicht angefasst werden. Hier muss man nur dran, wenn sich was am Datenbank- Server ändert (er z.B. eine andere IP Adresse bekommen hat). Diese Datei ändert Kodi von sich aus nie.

Ich kann mich allerdings nicht erinnern mal nachträglich noch Quellen hinzugefügt zu haben. Hat man Ordnung in seiner Mediathek, sollte das nicht notwendig sein. Aber falls doch,... das macht man sicher nicht jeden Tag, weswegen der Aufwand durchaus vertretbar ist.

Hi.

Das letztere muss schon eine Weile nicht mehr sein. ich zitiere mal aus dem offiziellen Kodi Wiki:

"Note: Kodi v20 users don't need set "importwatched" or "importresumepoint" to true anymore as that's the default".

Man muss es nicht einschalten, sondern ausschalten, wenn man das nicht haben will. Daneben betrifft es nur das schreiben und lesen der Watchedstates aus eventuellen .nfo Dateien. Das wiederum hat erst mal nichts mit der zentralen Datenbank zu tun und wird nur angewendet, wenn man die Datenbank gezielt in .nfo Dateien exportiert oder importiert. Im "Alltag" werden die Gesehen Zustände in die Kodi Datenbank eingetragen und auch von dort aus gelesen und im GUI angezeigt. Somit sind sie automatisch synchron, da ja alle Kodi Instanzen dieselbe zentrale Datenbank verwenden. Letztendlich geht es ja genau darum, wenn man eine zentrale Datenbank statt vieler einzelner lokaler und nur für eine Kodi Instanz zuständige Datenbanken verwendet.

Der Im- bzw. Export der Daten aus der Datenbank ist eine aufwändige Aktion, die man in der Regel nur macht, sofern man größere Änderungen an der DB vornimmt (z.B. die Kodi Version wechselt). Dabei werden aber alle Änderungen, die man ggfs selbst an den .nfo mit einem externen Programm gemacht hat, verworfen. Nutzt man ausschließlich Kodi und hat vorher beim Scrappen nur "local info only" Scrapper verwendet, sollten die Daten in den .nfo und in der Datenbank weitestgehend übereinstimmen. Dann sollte das kein größeres Problem sein, kann aber dennoch schief gehen.

Ich lasse grundsätzlich kein Programm unkontrolliert Änderungen an meinen .nfo vornehmen. Damit habe ich mal extrem schlechte Erfahrungen gemacht, was mich mehrere Monate Arbeit gekostet hat, bis alles wieder so war, wie ich das haben will. Meine .nfo sind individualisiert, da die Online Datenbanken voller Fehler stecken, sei es das die Episoden/Staffel Nummern nicht stimmen (kommt bei länger laufenden Serien speziell aus Deutschland sehr oft vor), die Beschreibungen oder Titel nicht auf Deutsch übersetzt sind und, was so gut wie nie richtig ist, die FSK Einstufung. Hat man "Glück", bekommt man die amerikanische Einstufung, aber "unsere" FSK ist praktisch nie in den Online Daten zu finden. Und ich bevorzuge es definitiv, wenn das FSK 12 Logo angezeigt wird, nicht das PG Logo. Die .nfo sind für die Metadaten des Films, der Serie da, nicht für Abspielfunktionen eines einzelnen Programms, imho.

Die in Kodi integrierte Backup/Restore Funktion habe ich so gut wie noch nie verwendet. Muss ich die Kodi Datenbank übertragen (ohne die sowieso vorhandene Migrationsfunktion von Kodi beim Upgrade zu verwenden), mache ich das entweder mit SQL Befehlen oder ich nutze das Addon "WatchedList", um die Gesehen Zustände extern abzusichern. Wenn ich z.B. die Datenbank komplett neu aufbauen will, weil sich zu viel geändert hat und zu viele "Leichen" in der DB übrig geblieben sind, so das sie anfängt zu groß und zu langsam zu werden, habe ich das gelegentlich mal gemacht. Spätestens seit Kodi 21 ist das aber praktisch komplett überflüssig geworden, denn neuerdings erkennt Kodi den Austausch eines Videos, z.B. wenn man ein SD Video durch eines in 4k austauscht, und ändert nur die entsprechenden Mediainfos in der DB, statt einen komplett neuen Eintrag darin zu erzeugen (und den "Alten" trotzdem drin zu lassen), wie es früher bei jeder kleinsten Änderung der Fall war. Mit gut gepflegten .nfo bei den Videos und WatchedList hat man auf jeden Fall alles da, was nötig ist, um die DB zügig wieder neu aufzubauen, sollte mal etwas schief gehen. Deswegen bin ich so "pingelig" mit meinen .nfo und lasse nichts daran herum "pfuschen".