MariaDB für Kodi, Howto

Am Samstag (06.09.25) Vormittag werde ich ein Update der Forensoftware (inkl. aller Plugins) durchführen. Das Forum wird deshalb auf unbestimmte Zeit nicht verfügbar sein. Neuigkeiten wird es im Matrix Chat geben: https://www.kodinerds.net/thread/79927-freischaltung-matrix-chat/
  • 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 "as.xml.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 "as.xml.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.

    <as.xml>

    <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>

    </as.xml>

    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 "as.xml.xml" Datei, idealerweise auf dem NAS in einem extra Ordner (bei mir heißt er "Kodi-Files"). Von dort wird die "as.xml.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 "as.xml.xml"... Könnt ihr aber machen, wo und wie ihr wollt, so lange die "as.xml.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 as.xml.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.

    -------------------------------------
    Danke fürs lesen, Claus

  • 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 as.xml.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.

    -------------------------------------
    Danke fürs lesen, Claus

  • Und wer mit einer gemeinsamen Datenbank und mehreren Clients arbeitet, hat vielleicht auch Interesse, den "gesehen-Status" darüber zu synchronisieren und nimmt dann fogendes in die as.xml.xml auf:

    Code
    <videolibrary>
    		<importwatchedstate>true</importwatchedstate>
    		<importresumepoint>true</importresumepoint>
    		<dateadded>1</dateadded>
    	</videolibrary>
  • Ich denke, da hast du was missverstanden, no.spam. importwatchedstate und importresumepoint beziehen auf .nfo Files. Das kann wichtig sein, wenn man DB exportiert und wieder importiert. Der gesehen-Status wird beim normalen Nutzen der Clients von vorne herein automatisch synchronisiert. https://kodi.wiki/view/Advancedsettings.xml#videolibrary

    dateadded 1 ist übrigens default. Persönlich finde ich das nicht intuitiv, ein Feld "wurde zur Bibliothek hinzugefügt am" zu haben, und dann aber per Default gar nicht dieses Datum zu nehmen sondern das Filedatum des Medienfiles.

    Kodi 21.2, 17.6, 21.1, 16, 21.2 on Windows 11 Pro, Android 6, Android 12, FireTV Box 2nd Gen, FireTV 4k Max 2nd Gen
    Media on NAS, OpenMediaVault 7 (Debian Linux).

  • dateadded=0 wäre das Datum an dem es zugefügt wurde, einfach

        <videolibrary>
            <dateadded>0</dateadded>
        </videolibrary>
        <musiclibrary>
            <dateadded>0</dateadded>
        </musiclibrary>

    in die advanced.xml und die Filme werden bei "zuletzt Hinzugefügt" richtig angezeigt. Das kann man auch gleich für dei Musik machen dann gehts auch da.

  • 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".

    -------------------------------------
    Danke fürs lesen, Claus

  • Ich muss hier nochmal einhaken. Wo wird die Information, welcher Film schon ganz oder teilweise gesehen wurde, bei einer lokalen Database gespeichert? Ich dachte, es sei in MyVideos131.db gespeichert, aber offenbar ist es die Textures13.db?

    Ich habe die Bibliothek entsprechend der Anleitung in https://kodi.wiki/view/MySQL/Setting_up_Kodi in Multiple Files exportiert. Der angelegte Sicherungsordner enthält 5 leere Ordner (actors, movies, moviesets, musicvideos, tvshows) und eine videodb.xml mit dem Inhalt

    XML
    <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
    <videodb>
        <version>1</version>
        <paths />
    </videodb>

    Wie soll man die Information, welcher Film schon ganz oder teilweise gesehen wurde, also exportieren??

    Ich habe auf einem Datenserver mariadb installiert und für User Kodi eingerichtet, wie hier beschrieben. In der Kodi-Installation habe ich die advancedsettings.xml wie im Kodi-Wiki beschrieben eingerichtet. Dann den Sicherungsordner importiert. Auf dem Datenserver tut sich auch was:

    Aber das einzige, was sich da fortwährend aktualisiert ist die Datei ib_logfile0, die sich nicht anzeigen lässt (keine Textdatei). Eine Textures13.db gibt es nicht. Jedesmal, wenn ich einen Film abspiele, aktualisiert Kodi munter weiterhin seine lokale Textures13.db. Das Ziel, die Information, welcher Film schon ganz oder teilweise gesehen wurde, zentral für mehrere Geräte vorzuhalten, erreiche so also nicht. Was läuft da falsch?

  • Hi.

    Wo wird die Information, welcher Film schon ganz oder teilweise gesehen wurde, bei einer lokalen Database gespeichert? Ich dachte, es sei in MyVideos131.db gespeichert, aber offenbar ist es die Textures13.db?

    Die 131 ist von einer schon älteren Kodi Version, das kann ich nicht mehr nachschauen. In den aktuellen DB Versionen (Kodi 21 oder 22, also 133 bis inzwischen 137) wird die Abspielposition bei teilweise gesehenen Filmen in der Tabelle "bookmark" innerhalb der MyVideosXXX DB gespeichert. Sobald der Film ganz angeschaut wurde, wird er wieder aus bookmark entfernt, dafür dann aber der Playcount auf 1 (genauer um +1 erhöht) gesetzt. Der Playcount, also ob ein Film schon komplett und wenn ja, wie oft gesehen wurde oder noch nicht, ist in der Tabelle "files" zu finden, und das schon ewig, also mit Sicherheit auch in der Myvideos131...Ob das mit "bookmark" auch schon in der 131 der Fall war, kann ich aus dem Stand nicht sagen. Ist aber gut möglich.

    Das hat übrigens rein gar nichts damit zu tun, ob man MySQL/MariaDB verwendet oder die lokale Kodi SQLite Datenbank im Einsatz ist. Die Datenbank- Struktur ist in beiden Fällen absolut identisch.

    In der TexturesXXX.db (XXX steht halt für die aktuell gültige Version, in deinem Beispiel ist das 13 also Textures13.db oder eben Myvideos131.db) werden die Pfade zu Grafiken, Logos, Fanart, usw. gespeichert, die im Kodi GUI genutzt werden. Das hat aber nichts mit der eigentlichen Datenbank zu tun. Die wird auch bei MariaDB als lokale Datenbank verwendet und lässt sich nicht zentral in MariaDB speichern. Die Pfade zu den Grafiken kann je nach Gerät völlig anders aussehen, weswegen das nicht so einfach zentral ausgelagert werden kann. Das bleibt auch weiterhin eine individuelle Angelegenheit pro Gerät. Allerdings werden die Pfade, sofern das noch nicht geschehen ist, automatisch eingepflegt, sobald die entsprechende Grafik auf dem lokalen gerät zum ersten Mal benötigt wird. Deswegen wird die Textures13.db ständig aktualisiert, eben immer dann, wenn eine bishe rnoch nicht genutzt Grafik angezeigt werden soll.

    Das Ziel, die Information, welcher Film schon ganz oder teilweise gesehen wurde, zentral für mehrere Geräte vorzuhalten, erreiche so also nicht.

    Wie gesagt, das hat rein gar nichts mit der Textures13.db zu tun. Die dafür notwendigen Informationen werden ganz sicher in der Myvideos131 gespeichert.

    Wie soll man die Information, welcher Film schon ganz oder teilweise gesehen wurde, also exportieren??

    Welcher Film schon einmal ganz gesehen wurde, kann man mit mehreren Tools/Addons absichern und später auch wieder importieren. Dazu zählt z.B das Addon Watchedlist, mit dem man das bewerkstelligen kann. Auch mit meinem Programm Kodi-Backup kann man in der veröffentlichten Version nur komplett gesehene Filme/Episoden und, als einziges Tool bisher auch von nicht kategorisierten Videos absichern und zurückschreiben. Für die Apsielpositionen teilweise gesehener Filme gibt es aktuell keine Lösung, gar keine. Ich arbeite aber grade an einer Lösung, um auch die "Halb gesehenen" Filme incl. der letzten Abspielposition absichern zu können. Die Version ist aber noch nicht zur Veröffentlichung geeignet (ist noch Pre Alpha), funktioniert für MySQL/MariaDB schon zum größten Teil. Es wird aber noch eine ganze Weile dauern, bis die Version soweit ist, extern getestet zu werden.

    -------------------------------------
    Danke fürs lesen, Claus

  • Laut https://kodi.wiki/view/Databases/MyVideos war es bei Kodi 20 die MyVideos121.db, dann dürfte für mein Kodi 21.2 die MyVideos131.db aktuell sein. Das ist ja auch die Datei, die Kodi 21.2 auf dem mysql-Server neu angelegt hat.

    Kodi 22 mit MyVideos133.db ist für CoreElec ng-stable nicht verfügbar.

    Nun stellt sich die Situation so dar:

    • eine lokal installierte MyVideos131.db enthält die gewünschten Informationen (Position + Playcount) und wird auch bei jeder Veränderung aktualisiert
    • Exportiert man diese Datenbank in multiple Dateien, werden diese Informationen offenbar nicht gesichert.
    • Nach Abänderung der Datenbank auf einen zentralen Server wird dort eine leere MyVideos131.db angelegt. Es ist aber weder möglich, dort die Daten aus der vorherigen lokalen MyVideos131.db zu importieren (weil die Daten zu Position + playcount im Export fehlen) noch ändert sich Datum oder Dateigröße der /var/lib/mysql/MyVideos131.db, wenn man neue Filme abspielt. Offenbar werden die tatsächlichen Daten doch nur in /var/lib/mysql/ib_logfile0 angelegt, denn das ist die einzige Datei auf dem Server, die sich nach dem Abspielen eines Films verändert. Testweise habe ich die lokale MyVideos131.db gelöscht, und dennoch werden Position und Playcount von Kodi richtig
      angezeigt - die mysql-Datenbank scheint also richtig zu funktionieren, nur dass ich jetzt wieder bei 0 anfange.

    Ich muss dazu sagen, dass ich eine wohl eher untypische Art habe, Kodi zu nutzen. Die Filme liegen in Tausenden von Dateien auf einem NFS-Server. Die Dateinamen sind z.T.. kryptisch. Vieles sind auch eigene Kameraaufnahmen. Es gibt keine nfo-Dateien. Wenn ich diesen Server in Kodi als Quelle hinzufüge, sage ich im Menü bei der Frage "Inhalt festlegen" immer "Dieser Ordner beinhaltet: keine". Ich möchte nicht, dass ein Scraper nach Coverbildern sucht, weil das sowieso in zu vielen Fällen falsche Treffer ergeben würde. Ich nutze die Datenbank also nur für Position + Playcount. Für alles andere, so schick es auch sein mag, fehlt mir schlichtweg die Zeit und Lust.

    Nachtrag: Anscheinend habe ich die Vorgabe des Wikis, die Bibliothek in "multiple files" zu exportieren, falsch verstanden. Ich habe das als "(viele) einzelne Dateien" übersetzt und daraufhin im deutschen OSD die Export-Methode "Einzelne" ausgewählt. Gemeint war mit multiple aber wohl "Separat". Nun ist es offenbar aber so, dass Kodi bei dieser Methode lauter nfo-Dateien in den (Unter-)Ordnern ablegen will, in denen sich der jeweilige Film befindet. Das scheitert aber daran, dass Kodi keine Schreibrechte auf dem NFS-Server hat. Und selbst wenn die nfo-Dateien Position und Playcount enthalten sollten, ist der Sinn und Zweck des zentralen mysql-Servers doch, dass diese Informationen dort liegen sollen. Jetzt nehmen wir mal an, beim Import würden die dann tatsächlich aus den nfo-Dateien zusammengesucht und in der Datenbank abgelegt. Und was wird dann mit den ganzen nfo-Dateien? Bleiben die bzw. die darin gespeicherten Position und Playcount -Infos als Karteileichen ewig auf dem NFS-Server?

  • Exportiert man diese Datenbank in multiple Dateien, werden diese Informationen offenbar nicht gesichert.

    Sollten doch, dort sollte der watchedstate und resumepoint drinstehen. Die werden seit Version 20 von Kodi (standardmäßig) mit importiert.

    Und was wird dann mit den ganzen nfo-Dateien? Bleiben die bzw. die darin gespeicherten Position und Playcount -Infos als Karteileichen ewig auf dem NFS-Server?

    Die bleiben bestehen bis Du sie löscht.

    --------------
    Guides nicht mehr verfügbar wegen Youtube unvermögen guten von schlechten Kodi Videos zu unterscheiden.

  • Exportiert man diese Datenbank in multiple Dateien, werden diese Informationen offenbar nicht gesichert.

    Nein, werden sie nicht. Übrigens auch nicht, wenn man die DB in eine einzige Datei absichert. Das kann man nur über SQL Export und Import lösen. Dabei werden jedoch oft irgendwelche ID durcheinander gebracht, da im laufe der Zeit ständig Lücken entstehen. Zumindest der Gesehen Zustand von vollständig gesehenen Filmen/Episoden wird in die entsprechende .nfo geschrieben, wenn man die Kodi DB in getrennte Dateien exportiert.

    Nun ist es offenbar aber so, dass Kodi bei dieser Methode lauter nfo-Dateien in den (Unter-)Ordnern ablegen will

    Ja genau, das ist exakt der Sinn von solchen .nfo Dateien. Die gehören direkt zu den einzelnen Videos. Dort sind die Metadaten zum Film, zur Episode hinterlegt und müssen deswegen nicht erst langwierig und umständlich aus dem Internet geladen werden. Lokale .nfo Dateien beschleunigen den Import der Mediensammlung in die Datenbank enorm. Deswegen gibt es unzählige Tools, die solche .nfo Dateien (die neben Kodi auch von so ziemlich jeder anderen HTPC Software verwendet werden) vorab und wesentlich komfortabler als aus Kodi heraus erzeugen können, die Dateien gleich passend umbenennen und die notwendige Fanart aus dem Internet laden und ebenfalls zu den Videos legen. So ist ein Neu- Import der Bibliothek ein Kinderspiel. In aller Regel gibt es aber nur .nfo für Filme, Serien und, seltener, Musikvideos. Weil es kaum ein Programm gibt, das solche .nfo auch für "Keine" verwenden kann.

    Die Gesehen Zustände werden ohne extra Tools nur beim erstmaligen Einlesen der ,nfo ausgelesen und erst dann wieder geändert, wenn man die Datenbank erneut exportiert. Es gibt aber ein Addon, das diese Einträge in den .nfo automatisch aktualisiert, aber eben nur für Filme/Serien, nicht für "keine". Ohne Schreibzugriff auf den Medien- Ordner ist das alles sowieso hinfällig. Der Schreibzugriff für Kodi ist dabei eine Grundvoraussetzung, ohne den es einfach nicht funktionieren kann.

    Die Filme liegen in Tausenden von Dateien auf einem NFS-Server. Die Dateinamen sind z.T.. kryptisch. Vieles sind auch eigene Kameraaufnahmen.

    Du nutzt also Kodi nur als reinen Video-Player. Ok, das ist nicht der eigentliche Zweck von Kodi, aber na gut. Wenn du immer nur "Keine" nimmst, helfen dir die .nfo sowieso nicht, denn Kodi liest die Playcounts usw. aus den .nfo nur für Filme/Serien/Musikvideos. "Keine" ist dabei außen vor. "Keine" wird in aller Regel nur dann verwendet, wenn es sich um nicht kategorisierbare Videos handelt wie etwa deine selbst gefilmten Videos, die wohl nicht bei IMDB eingepflegt worden sind. Denn der Sinn von Kodi ist es ja vorrangig, die Medien "schön" zu präsentieren. Dazu gehören eben neben der Fanart auch die vielen Metadaten, die man aus Online Bibliotheken wie IMDB, TVDB usw. gewinnen kann. Aber eben nur, wenn es sich um Spielfilme, Serien- Episoden oder Musikvideos handelt, nicht um selbst gefilmte Videos o.Ä.

    Videos, die als "Keine" eingepflegt wurden, werden obendrein erst dann in die Datenbank aufgenommen, wenn sie das erste Mal abgespielt oder wen sie manuell auf "Gesehen" gesetzt werden. Bis dahin erscheinen die Videos aus "Keine" Quellen nicht in der DB. Wenn du auf ein Windows System Zugriff hast (bzw ein System mit Wine), kannst du es mal mit dem oben verlinkten "Kodi Backup" versuchen. In der aktuell online verfügbaren Version werden zumindest mal die Playcounts von unter "Keine" zu findenden Videos abgesichert, so weit mir bekannt ist als einziges Tool überhaupt, dass das ohne den Umweg über eine .sql Datei zu gehen, kann. Die Abspielpositionen von den Videos werden noch nicht mit abgesichert. Ich arbeite wie gesagt daran, aber das wird noch dauern. Um das oben erwähnte Problem der noch nicht eingelesenen Videos zu umgehen, kann man manuell alle Videos (geht auch von einem übergeordneten Verzeichnis aus für ganze Ordner auf einmal) als "gesehen" markieren und anschließend wieder alle als "Nicht gesehen". Durch diesen Workaround stehen alle Videos in der DB und der Import der Playcounts funktioniert ohne "Verluste".

    Wenn du Die DB 1 zu 1 von der lokalen SQLite Datenbank auf die zentrale MySQL Datenbank übertragen willst, kannst du mit einem SQLite GUI- Tool wie DB Browser for SQLite die komplette Datenbank in eine .sql Datei exportieren und sie anschließend mit sowas wie PHPMyAdmin dann in die MySQL/MariaDB Datenbank importieren. Allerdings kann niemand dafür garantieren, das alle ID und Zähler noch passen. Aber einen Versuch ist es wert. Das ist aktuell die einzige Möglichkeit überhaupt, ohne .nfo und ohne extra Addon die Playcounts und Last Positions zu übertragen. Wie gesagt, "Keine" Videos sind nur eine vernachlässigte "Randerscheinung" bei Kodi, weswegen du es quasi "zweckentfremdet" verwendest. Dann muss man mit Einschränkungen leben.

    Allerdings würde ich echt mal schauen, ob es für deinen doch sehr untypischen Einsatzzweck nicht besser geeignete Tools (Media Player) als Kodi gibt. GGFS ist sogar schon VLC etwas, womit du vielleicht weniger Umstände hast. Das, was du machst, ist einfach nicht das, wofür Kodi ursprünglich gemacht wurde. Es geht zwar, aber eben mit Einschränkungenund einen Haufen Overload, der mitgeschleppt wird für an sich nützliche Funktionen, die du aber bewusst nicht nutzt. Ist ungefähr so, als ob du zum Brötchen holen mit einem 40 Tonner anreist. Der LKW schafft die Brötchen zwar spielend, aber ein Fahrrad eben auch...

    -------------------------------------
    Danke fürs lesen, Claus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!