Wo werden die Dateipfade der Thumbnails (z.B Cover) gespeichert?

Hi. Ich habe kein technisch Problem aber ich würde gerne verstehen wie etwas funktioniert

Kurz zu meiner Konfiguration:

Verwende Kodi mit Maria DB, Thumbnails sind per <pathsubstitution> ausgelagert- liegen zentral im Netzwerk.

Ändere ich, sagen wir mal ein Cover, ziehen sich meine Clients das aktuelle Cover aus dem zentralen Thumbnail - Speicher, klappt wunderbar.

Suche ich mir nun exemplarisch ein Cover Thumbnail aus dem Thumbnail Speicher ist dieses auch eindeutig benannt z.B:

\\NETZWERKSERVER\kodi_thumbs\5\73a72dfa4.jpg.

In meiner Maria DB finde ich 3a72dfa4.jpg oder den Netzwerkpfad aber nicht. Ich würde hier erwarten, dass

in der DB hier eindeutige Einträge zu finden sind - denn woher soll der Kodi Client sonst wissen wo das Thumbnail liegt!?

Weiß hier jemand wie die Speicherung der Thumbnails technisch funktioniert und was dort für eine Logik hinter steckt?

Die liegt aber nicht im Netzwerk, sondern lokal auf den Clients. Wenn ich bei Client A ein Cover ändere, wird es schlussendlich auch auf Client B übernommen, der bekommt aber ja nicht die Textures13.db vom Client A sondern irgendwoher die Daten wo das Thumb liegt...

Zitat von buers

Ich kenne die interne Struktur der DBs in Kodi nicht sehr gut. Allerdings weiß ich, dass Kodi für die URLs der Thumbnail-Quelle einen Hash-Wert generiert. Ich nehme an, die Quell-URL steht in der DB. Daraus wird ein 32-bit Hash Wert generiert (Kodi nutzt CRC32). Den kann man jederzeit sehr schnell aus der URL berechnen. Dieser 32-Bit Wert wird Hexadezimal dargestellt (also mit Ziffern 0-9 und Buchstaben a-f. Dein Beispiel scheint paar Vertipper zu enthalten - daher erfinde ich ein neues Beispiel. Bei mir hasht die URL zum "Ganz oder Gar nicht" Cover zu 7e8ee14a. Der Name des Thumbnails heißt dann 7e8ee14a.jpg. Abgespeichert wird er in einem Ordner "7" (das erste Zeichen des Hashwertes) - also irgendwo in Kodi-Verzeichnis/userdata/Thumbnails/7e8ee14a.jpg.

Die Erklärung ist sehr verkürzt und erfordert bisschen Kenntnisse (von nicht total ganz alltäglichen) IT-Begrifflichkeiten und Konzepten.

Komm selber aus dem IT - Bereich. Sowas hab ich mir gedacht aber im Netz keinerlei Infos gefunden. Mein Beispiel war "ausgedacht", sollte das Prinzip der Ablage aufzeigen. Wäre natürlich noch interessant zu wissen, welche Quell-URL zur Generierung des Hash Wertes genutzt wird (finde ich sicher selber heraus). Meine Frage ist beantwortet! Besten Dank

Zitat von DaVu

Und jeder Client hat seine eigene TexturesXX.db

Diese zu zentralisieren könnte zu Problemen führen. Man kann sie auslagern via PathSubstitution. Das müsste dann aber jeder Client machen und würde so entsprechend Platz von jedem Client auf dem NAS belegen. Über die PathSubstitution eine Art Zentralisierung zu bewerkstelligen ist eher "solala" und wäre nicht das, was ich empfehlen würde.

Je nach Netzwerkgeschwindigkeit könnte es mit ausgelagerten Thumbs auch zu längeren Ladezeiten bei den Covern kommen.

Wenn du das Cover auf Client "a" änderst verweist du auf ein anderes Bild. Der Pfad zum Bild ist in der MyVideos.db gespeichert. Das Feld sollte laut Wiki "c08" sein (Image URL). Ändert sich das Bild und du schreibst das in deine MySQL/MariaDB dann ändert es sich für alle Clients und alle Clients schreiben dann den neuen Hash in ihre lokalen TexturesXX.db Dateien

Verstehe. Mir ging es bei meiner Frage genau um diese Thematik, da ich mich gefragt habe ob es zu Wechselwirkungen/Problemen führt, wenn in der DB keine eindeutige URL hinterlegt ist. Habe einen gemeinsamen Thumb Speicher, den alle Clients nutzen, der liegt auf der Nas. Ich habe das Konstrukt in der Form um die 10 Jahre am laufen, konnte noch keine Probleme feststellen... Aber das es eher suboptimal ist, sehe ich mit dem Hintergrund wissen ein. Danke für den Input!

Zitat von buers

Zum Thema Teilen der Thumbnails, siehe auch RE: Wie erreiche ich 24p-Wiedergabe mit TV, AV-Receiver, FireTV 4K Max (Gen.2) und KODI 21? und ff. Persönlich sehe ich kein grundsätzliches Problem nach Analyse des Quelltext. Aber selbst Team-Kodi Mitglieder scheinen das nicht alle gleich zu sehen.

Ein Argument, was ich fand, ist dass die verwendeten Thumbnails auch vom Gerät abhängen können (sagen wir mit 4k Bildschirm anders als mit altem VGA-Bildschirm, wo kleinere Auflösung reiche). Aber dann wäre nach meinem Verständnis das ganze Konzept kaputt. Mein Notebook nutzt mal das eigene Display, mal einen externen Monitor, mal den Fernseher mit wieder anderer Auflösung. Und, nach meinem Quelltext-Verständnis würde es eh trotzdem noch klappen. Wahrscheinlichkeit von Hash-Kollisionen steigt. Aber das ist kein neues prinzipielles Problem. Das Problem ist eh schon da bei ungeteiltem Thumbnail-Ordner Ordner.

Ich hab einen ähnlichen Mix: Raspberry, Fire-TV, PC und konnte über Jahre hinweg keine Kollisionen beobachten (mag sein das es mal welche gab die mir nicht aufgefallen sind). Für mich funktioniert der gemeinsame Thumbnail Cache somit recht gut (auch wenn prinzipbedingt das ganze nicht sauber ist). Danke für den Input!

Abschließend wollte ich (falls jemand sich die gleichen Fragen stellt) noch einmal kurz das Prinzip erklären (hab mir das noch einmal genauer angeschaut).

Dazu auch eine kurze Erläuterung und Fix meines Problems, welches mich zu dieser Frage bewogen hat.

Grundsätzlich werden die Thumbs bzw. die URL der Bilder Quelle in der Tabelle "Art" gespeichert, anhand der ID den Serien/Filmen zugeordnet.

Hier wird ausschließlich die Quell URL gespeichert aus der dann schlussendlich das Thumbnail und Hashwert generiert und im Thumbnail/Artworkcache (bei mir zentral) abgelegt wird. In der Regel sind die Quell URLs Pfade zu den Online Covern, Actors, etc. der Scraper Beispiel:

https://image.tmdb.org/t/p/original/6vwdsO3wG26DatBgkVyPY9OjnDL.jpg

Solange diese URLs erreichbar sind (was bei sehr alten Datenbanken wie meiner nicht immer der Fall ist) könnte man sogar gefahrlos die lokale Textures DB der Clients löschen, den zentralen Thumbnail/Artworkcache leeren, da die Thumbs danach einfach neu generiert werden würden aus den Quell URLs.

Ist nun der lokale Thumbnail/Artworkcache korrupt (das war bei mir der Fall durch einen Raid Defekt) und man muss diesen löschen/neu erstellen, bekommt man in der Realität das Problem, das Thumbs zu einigen Einträgen fehlen werden (Quell Bild nicht mehr per URL erreichbar).

Ich hab für mich einen recht einfachen Fix gefunden, wie man die bestehenden Thumbs wieder an alle Clients verteilt bekommt:

Voraussetzung ist eine komplette Sicherung der DB (aus Kodi) zum Zeitpunkt wo das System noch intakt war! Macht man hier: Bibliothek -> Bibliothek Exportieren -> in Einzelne Datei.

Hier wird ein Export Ordner erstellt der die komplette Video DB und (das ist das Entscheidende) alle Cover extrahiert aus dem Thumbnail/Artworkcache enthält.

Im nächsten Schritt habe ich die Video DB in Maria, den zentralen Thumbnail/Artworkcache , die lokale(n) Textures.db gelöscht.

Die Sicherungsdatei bzw. den Ordner habe ich nun im Netzwerk abgelegt (hier bietet sich der gleiche Ordner wie der zentrale Thumbnail/Artworkcache an).

Der Schritt die Sicherung im Netzwerk zu speichern ist notwendig, da wir ja wollen, das alle Clients Zugriff auf diese Daten haben (auf einem lokalen LW: C: gestaltet sich sowas schwierig).

Im nächsten Schritt lesen wir nun über einen beliebigen Client die Sicherungsdatei über den Netzwerkpfad ein. Macht man hier: Bibliothek -> Bibliothek Importieren -> Zeroconf Browser um auf die Netzwerkfreigabe der Sicherung zu gelangen, danach Import!

Anschließend sollte die komplette DB incl. aller Cover soweit wieder vorhanden sein und alle Clients können diese Thumbs auch (ohne funktionierende Online Quell URL) abrufen denn:

Beim einspielen der Sicherung wird in der "Art" Tabelle nun als Quell URL der lokale Netzwerkpfad zum Thumb der Sicherung gespeichert (Sicherung liegt für alle verfügbar ja nun im zentralen Thumbnail/Artworkcache ) jeder Client kann hier nun die Thumbs abrufen um Hash Werte zu generieren, das Thumb neu im zentralen Thumbnail/Artworkcache ablegen.

Das ganze Konstrukt "Gemeinsame Thumbs + geteilte DB" ist schon wie @DaVu sagte "solala" aber wenn wann die technischen Hintergründe kennt zu händeln.

Input zu Artworkcache findet man im Kodi Wiki: Artwork/Cache im Kodi Wiki

Bei einer Neuinstallation würde ich das ins Auge fassen. Ohne zu sehr ins Detail zu gehen, meine Datenbank/Mediathek ist alt, groß, die älteren Medien aus heutiger Sicht auch schlecht benannt. Der Aufwand wäre hoch und käme eine Neuinstallation gleich. Um das nachhaltig und sinnvoll umzusetzen müsste die Medienablage, Benennung komplett überarbeitet werden.

Bis auf die "Verwaltung" der Thumbs bin ich zufrieden, läuft im großen und ganzen seit mehr als 10 Jahren problemlos, deswegen lasse ich es so.