Kodi Datenbank wird nicht richtig bereinigt

Hi.

Da ich im Moment nach einer "weniger gefährlichen" Alternative zu WatchedList suche (WL überschreibt bei jedem Start die Playcounts in der Kodi Datenbank, weil man es nicht getrennt Backup und Restore machen lassen kann) und ich die Varianten mit dem Playcount in den .nfo oder einem Online Dienst wie Trakt einfach nicht mag, habe ich mir mal die Kodi Datenbank genauer angeschaut, ob ich da vielleicht auf die Schnelle etwas selber programmieren kann. Eigentlich sollte das nicht zu schwer sein, ein paar einfache SQL Abfragen und gut ist.

Dabei ist mir aufgefallen, das die Tabelle "files" unglaublich groß und zugemüllt ist. Jedes Video, jede TV Aufzeichnung, jeder Stream, alles, was ich in den letzten Jahren (seitdem diese Datenbank existiert, die schon mehrfach migriert wurde beim Wechsel der Kodi Hauptversion) jemals mit irgendeinem Kodi angeschaut habe, steht da auf alle Ewigkeit drin. Und das häufig mehrfach. Besonders auffällig bei nicht kategorisierten Videos (ich habe viele Dokus usw. die nicht in Serien oder Filme passen), die scheinbar jedes Mal, wenn man in das entsprechende Verzeichnis navigiert, erneut ans Ende der Tabelle angehängt werden. Für die Tabelle "path" gilt im Prinzip dasselbe. Auch da wird alles für alle Ewigkeit gespeichert. Da der Playcount eben nur in der Tabelle "files" zu finden ist, muss man ständig mit diesem Moloch hantieren. Die "offizielle" Datenbankbereinigung tastet diese Tabellen gar nicht an, sondern nur Filme, Episoden und Serien (vielleicht auch noch Musikvideos, davon habe ich aber kaum was, fällt in dem Wust von Einträgen jedenfalls nicht auf).

Alleine dadurch, das ich mit jeden Tag die regionale Nachrichtensendung mit MediathekView lade, anschaue (ohne sie in die DB einzulesen, wüsste auch nicht wo) und dann wieder lösche, gibt es eine wahre Flut von verwaisten Pfaden und Dateien.

Das ist doch nicht richtig so, oder? Eigentlich müsste die Datenbankbereinigung doch alles aus der Datenbank entfernen, was nicht mehr existiert. Tut sie offenbar aber nicht. Kein Wunder, das Kodi mit der Zeit immer lahmer wird und man immer schnellere Geräte braucht...

Gibt es irgendeine Möglichkeit, das zu beheben außer sowas selber zu programmieren?

Das Einzige, das ich bisher gefunden habe, ist die radikale Lösung mit dem kompletten Löschen der Datenbank selber und alles wieder neu aufsetzen. Das ist aber extrem mühsam und Zeitaufwändig und erfordert obendrein eine sichere externe Backup Möglichkeit für die Playcounts... Das komplette Leeren der Tabellen "files" und/oder "path" würde die DB völlig unbrauchbar machen, also ebenfalls einen totalen Neuaufbau der Datenbank bedeuten. Das ist also keine sinnvolle Option.

Ja, wo Emby doch so super "nutzerfreundlich" ist und einem alle Entscheidungen ungefragt abnimmt. Egal ob man selbst die .nfo verändert hat oder ob man auf keinen Fall Transkoding haben will, Emby weiß prinzipiell alles besser. Mit Emby habe ich mir schon einmal meine ganze Mediathek versaut, was mich Monate an Arbeit gekostet hat, bis ich den Schaden wieder repariert hatte. Ist zwar schon Jahre her aber ich werde in diesem Leben wohl kein Freund von Emby mehr, fürchte ich.

Davon ab sind die Playcounts ja auch in der Kodi DB auf dem Server (MariaDB) gespeichert, genau wie bei Emby. Und genau wie bei Emby sind sie dann weg, wenn man die DB neu macht/machen muss. Man braucht auf jeden Fall eine externe Absicherung, unabhängig von der eigentlichen Datenbank.

Zitat von klarahimmel

Sinn sollte es doch eigentlich sein, das KODi durch die zentrale Datenbank schlank mit wenig Speicher wird, oder?

Nein, denn die Datenbank selbst belegt so gut wie keinen Speicherplatz. Das, was den Speicher belegt ist die Fanart, die in Kodi angezeigt wird. Aus Performancegründen werden die Grafiken auf jedem Kodi- Gerät lokal zwischengespeichert. Das können dann ganz unabhängig von der verwendeten Datenbank einige GB Speicherplatz sein. Dabei ist es völlig egal ob man Emby, Plex, Jellyfin, MariaDB oder die lokalen SQLite Datenbanken von Kodi selbst verwendet. Das Cachen der Grafiken wird trotzdem immer gemacht. Sobald auf dem entsprechenden Kodi Gerät eine bestimmte Grafik zum ersten Mal angezeigt wird, wird sie dabei lokal abgespeichert. Deswegen ist der Speicherplatz bei häufig und umfangreich genutzten Kodi Instanzen auch deutlich größer als auf Klienten, die nur selten mal genutzt werden. Zumindest bis alle Grafiken mindestens einmal angezeigt wurden. Ab dann wird der Platzbedarf nur noch unwesentlich größer. Der Speicherplatzbedarf ist eben der Preis dafür, das Kodi so "schön" ist und so viele optische Schmankerl bietet. Deswegen käme mir auch nie in den Sinn, statt Kodi die im Vergleich erheblich "hässlicheren" Apps von Emby, Plex oder Jellyfin zu verwenden, auf gar keinen Fall.

Die externe Datenbank dient dazu die Metadaten (Beschreibung, Rating,...) sowie die Gesehen Zustände auf verschiedenen Kodi Installationen synchron zu halten, nicht zum Platz sparen. Nutzt man nur ein Kodi, kann man sich die externe Datenbank komplett sparen.

Zitat von buers

Wie könnte ich das nachvollziehen?

Einfach eine Video Quelle hinzufügen und als Typ "Keine" auswählen. Wenn du davon mehrere Quellen hast (so wie ich), werden die Videos jeweils beim ersten browsen in das entsprechende Verzeichnis in die Kodi DB (Tabelle "files") eingetragen. Wenn man später, nachdem man einige andere solcher Verzeichnisse mal besucht hat, werden die Videos schon mal erneut eingelesen.

Hier mal ein Ausschnitt aus meiner Kodi Datenbank. Die hier aufgelisteten Tutorial- Videos liegen seit Anbeginn immer im exakt gleichen Pfad. Trotzdem steht jedes Video dreimal in der Tabelle, mit jeweils unterschiedlicher pathID und fileID. Dabei hat sich nie etwas an den Pfaden geändert. Außerdme habe ich sie bisher nur ein einziges Mal angeschaut.

Man sollte vielleicht dazu sagen, das meine Datenbank schon furchtbar alt ist und beim Wechsel der Kodi Hauptversionen immer automatisch migriert wurde. Ich denke, es war mit Kodi 18, als ich die DB das letzte Mal komplett neu aufgebaut hatte. Ich bin jetzt (wie die meisten anderen wohl auch) auf Kodi 21. Trotzdem sollten die "Leichen" beim Datenbank Bereinigen grundsätzlich entsorgt werden. Und das habe ich sicherlich schon mehrere Dutzend mal gemacht, seitdem ich die DB aufgesetzt habe.

Inzwischen habe ich spaßeshalber sowohl Emby als auch Plex und auch Jellyfin ausprobiert.

Plex hat sich gleich ins Abseits katapultiert, weil es mich dazu zwingt, einen Account anzulegen. Nur um das mal auszuprobieren lege ich doch keinen Account an. Die spinnen doch. Ich werde denen doch nicht sofort auf die Nase binden, was ich alles so zu Hause an Medien habe. Speziell, da ich vieles habe, was privat ist und privat bleiben muss. Damit sind ausdrücklich weder Pornos noch Raubkopien gemeint.

Jellyfin (und Emby) habe ich mit meiner lokalen Test- Mediathek ausprobiert. Da schien alles so weit zu funktionieren, mit dem Jellycon (Embycon) Addon. Sah aus wie Kodi Native und war, mit den wenigen Test- Medien auch anständig flott. Das Problem fing aber an, als ich zum Testen auch mal eine Quelle von einem Netzlaufwerk einbinden wollte. Jellyfin (und auch Emby) können (zumindest in der Windows Version) nicht mit UNC Pfaden umgehen. Man muss erst alles als Laufwerksbuchstabe mappen, wie armselig... Bei Emby stand zwar dabei, das man Netzlaufwerkspfade als //192.168.1.100 oder als //Server manuell eingeben kann. Doch tut man das, kommt immer nur "Ordner Network kann nicht gefunden werden"...

Was für ein Schrott. Dann quäle ich mich doch lieber mit der Kodi Datenbank herum und mache die alle paar Jahre mal komplett neu.

Ach, noch was... So wie es aussieht tauchen die mehrfachen Einträge tatsächlich nur oder vorrangig bei nicht kategorisierten Videos auf. Vermutlich, weil der Bereich eben nicht bereinigt wird. Bei Filmen und Serien-Episoden habe ich auf die Schnelle keine doppelten Einträge gefunden. Dafür aber bei Musikvideos:

Um das abzurunden.

Zitat von SkyBird1980

Ach du beschwerst dich das sich nach den Index einer neu erkannten Datei gekümmert wird beim Cachen als jede Datei unperformant am Path zu erkennen.

Du hast nicht verstanden, worum es geht. Es geht darum, das eine 100% identische Datei mehrfach mit demselben Pfad in der Datenbank steht und das dann auch die dazugehörenden Pfade mehrfach vorhanden sind. Das hat nix mit Index oder so zu tun, sondern mit nicht aufräumen können. Wenn sich aus irgendeinem Grund der Index der Datei ändert, muss der dann obsolete bisherige Eintrag beim nächsten Datenbank bereinigen entfernt werden, was er nicht wird. Dadurch tauchen die betroffenen Dateien eben mehrmals in der Datenbank auf, was sie nicht sollten.

Zitat von SkyBird1980

Das hinzufügen per UNC Pfad funktioniert übrigens sehr gut bei Emby.

Das ist bei dir offenbar Linux, nicht Windows. Genau das, was du in deinem Screenshot zeigt, tut es unter Windows nämlich prinzipiell nicht. Wenn man smb: vor den eigentlichen Pfad eingibt, will Windows eine App zum Öffnen von SMB Links installieren.

Bei der Eingabe ohne smb: davor (so wie das sonst bei Windows funktioniert), kommt bei Emby nur eine Fehlermeldung, das der Pfad nicht gefunden werden konnte.

Hi.

Alles gut, kein Problem.

Ich verwende zu Hause auf jedem Rechner denselben User mit demselben Passwort. Muss ich bei einem Linux System (von denen ich nicht viele habe) zusätzlich noch einen SMB (FTP,...) User für lokalen Zugriff anlegen, bekommt auch der denselben Usernamen und dasselbe Passwort. So brauche ich eigentlich nirgends eine extra Authentifizierung, da ich schon mit dem passenden User angemeldet bin. Da ich alleine lebe, ist es kein Problem, überall denselben User zu verwenden. macht das Leben dann aber doch einfacher. Auf jeden Fall hatte ich bei Emby die User/Pass Kombi bereit eingegeben, ohne das eine Verbindung zustande kam. Außerdem sollte das System im Zweifel nach einem Benutzernamen fragen, was ebenfalls nicht passiert. Das Problem ist scheinbar nicht die Authentifizierung, sondern das generell kein Zugriff aufs Netzwerk über UNC Pfade erfolgen kann. Es wird ja erst gar kein Ordner gefunden und auch kein anderes System im Netzwerk. Für lokale IP Adressen habe ich auf allen Systemen die Firewall komplett deaktiviert. Da reicht mir die Hardware Firewall zum Internet hin im Router aus. Das kann also auch nicht der Grund sein. Alle anderen Programme können problemlos per UNC auf meine Network Shares zugreifen, nur Emby und Jellyfin beide nicht. Ist schon komisch, da beide Programme zwar nicht identisch, aber zumindest ziemlich ähnlich sind. Man kann die Shares als Netzlaufwerk mappen, also einen lokalen Laufwerksbuchstaben hinzufügen. Dann kann Emby/Jellyfin ohne weiteres auf die Shares zugreifen. Aber das widerstrebt mir, da die Anzahl der freien Buchstaben endlich ist.

Zitat von SkyBird1980

Also wenn der UNC path z.B. in der Datenbank steht und Du nur die Quelle löscht ist er ja trotzdem erreichbar.

Kann sein. Aber warum muss dann der Pfad/die Datei noch mal eingelesen werden, wenn alles doch schon in der DB vorhanden und die Datei erreichbar ist? Daneben denke ich nicht, das ich die Quellen zwischenzeitlich gelöscht habe. Dazu bestand eigentlich überhaupt kein Grund. Andererseits ist meine DB schon so viele Jahre alt, das man sich einfach nicht mehr an alles erinnern kann.

Ich denke, so ganz sauber arbeitet Kodi hier wohl nicht. Ich muss das mit einer Test- Datenbank noch mal genauer vertiefen. Vielleicht finde ich ja exakt raus, was schief läuft und wie ich das in Zukunft vermeiden kann (sofern überhaupt möglich).

Einige Testergebnisse habe ich schon.

Zum einen, wenn man die Kodi DB als separate Dateien ausgeben lässt, dann sind die .nfo hinterher nur noch bedingt zu gebrauchen. Ich tausche gerne ältere Videos in minderer Qualität gehen solche in besserer Qualität aus, sofern ich entsprechende Videos in die Finger bekomme. Mache ich das, übernehme ich die .nfo von der schlechteren Version, da sich an den Metadaten (wie Episodennummer oder Beschreibung) ja nichts ändert, wenn man das eigentliche Video austauscht. So muss ich nichts ändern, um denselben Zustand wie vorher (nur eben mit einem besseren Video) zu bekommen. Beim neu Einlesen werde dann auch die Medien-Infos aktualisiert. Kodi schreibt aber beim Absichern der DB die Video- Informationen wie Codec, Auflösung usw. mit in die .nfo. Steht da sowas drin, hat man keine Möglichkeit mehr diese Werte in der DB zu ändern, da immer die Werte aus den .nfo bevorzugt werden. Das bedeutet, ich habe ein 4K DolbyVision Video und hatte vorher ein SD Mpeg2 Video, so wird das Video auch weiterhin in Kodi als Mpeg2 in SD Auflösung angezeigt, sofern ich nicht manuell diese Tags aus der .nfo heraus lösche und danach die Medieninformationen neu einlesen lasse. Dagegen, das Kodi den Playcount in die .nfo schreibt, hätte ich ja nichts, sofern das immer aktuell gehalten wird (dafür gibt es ein Addon). Aber ein richtiges Backup ist das auch nicht. Somit fällt die Lösung, Kodi einfach das Absichern der Playcounts zu überlassen aus. Ich will mir nicht alle meine 100.000 .nfo Dateien von Kodi "versauen" lassen. Also wird das neu Aufsetzen meiner Datenbank erheblich aufwändiger als erhofft. Auf Grund des vielen Mülls da drin werde ich kaum umhin kommen, das demnächst mal in Angriff zu nehmen.

Des weiteren werden trotz DB Bereinigung überhaupt keine Einträge aus den Tabellen "path" und "files" entfernt, auch wenn man die Quelle selbst entfernt hat. Liest man später dieselbe Quelle erneut ein, dann werden allerdings keine neuen Einträge (mehr) hinzugefügt, sondern die bestehenden Einträge weiter verwendet. Bei nicht kategorisierten Videos funktioniert das eigentlich genau so wie bei Filmen und Serien. Also sind die doppelten Einträge entweder beim DB migrieren entstanden oder das war ein Bug in einer älteren Kodi Version, der inzwischen behoben wurde. In sofern sehe ich das erst mal als erledigt an.

Nur das man aus der Tabelle nie wieder etwas raus bekommt, ist einfach nicht gut. Selbst wenn ich ein Video aus Kodi heraus lösche, wird es nicht aus der DB entfernt. Dazu kommt, das jedes Mal EPG nachladen (was hat das bitteschön mit Videos zu tun?), jedes Mal TV gucken und jeder Stream, den man mal angeschaut hat, hier ebenfalls für die Ewigkeit gespeichert wird.

Die verwaisten Einträge wird man nach meinem bisherigen Erkenntnisstand nur los, indem man die ganze Datenbank löscht und komplett von Vorne anfängt. Auf Dauer sicherlich keine Lösung.

Das Problem ist übrigens völlig unabhängig von der eigentlich verwendeten Datenbank. Denn das passiert genau so mit einer lokalen SQLite Datenbank (wie bei Kodi Standard) aber auch mit einer zentralen MySQL/MariaDB Datenbank oder Emby/Jellyfin, sofern man Embycon/Jellycon als Addon verwendet, was ja die Emby/Jellyfin Einträge in die Kodi DB überträgt.

Ich werde weiter forschen, ob man diese Probleme irgendwie in den Griff bekommt. Der Wechsel von der "richtigen" MariaDB Datenbank auf die lokale Test- DB ist ja schnell erledigt.