Wie werden Thumbnails gecached und benannt [Eden]

Das XBMC cached annähernd alles an Bildern, was es zur Darstellung vorgesetzt bekommt.
Zum einen, damit diese schneller geladen werden können und zum anderen, damit diese für die SQL-DB nachvollziehabr bleiben.
Die Benennung der Dateien erfolgt nach folgendem Schema:
Es wird ein CRC32-Wert aus dem Pfadnamen und dem Dateinamen (in Kleinbuchstaben) erstellt.
Und es wird ein Hash-Wert auf Basis der Dateigröße und dem Modifizerungsdatum erstellt, um zu erkennen, ob das Bild geändert wurde.

All das macht das XBMC schneller. Aber wer sich mal in den Thumbnailordner gewagt hat, der wird gesehen haben, dass er keine CRC-Prüfsummen lesen kann.
Jetzt nervt es natürlich, wenn man genau ein Thumbnail erneuern will, dass man dies im Thumbnailordner nicht finden kann.
Aber ... dafür gibt es das Webinterface des XBMC.

Man verbindet sich über das Webinterface mit dem XBMC und wählt den entsprechenden Eintrag aus.
Klickt man nun mit der rechten Maustaste auf das Cover, wird einem direkt oben der Name des gecachten Thumbs angezeigt.

Man kann natürlich auch auf "Bild öffnen..." klicken und bekommt dann den gesamten Pfad in der Adresszeile präsentiert:

http://192.168.1.15:8080/vfs/special://masterprofile/Thumbnails/Video/1/1c02cfad.tbn

Die Pfade für Fanart lassen sich mit dem Standard-Webinterface so leider nicht ermitteln.
Aber vielleicht findet da ja noch jemand etwas zu heraus.

Um den Datenbankeintrag des Image-Cache zu löschen, benötigt man auch den realen Pfad des Bildes.
Hier der übersetzte WIKI-Eintrag: (Die beschriebene Methode ist unter Linux)

--------------
Das Bild unter /home/x/.xbmc/addons/my.lovely.addon/icon.png soll geändert werden. Wenn man dies nun austauscht, verwendet das XBMC nach wie vor das gecachte Bild.
Also muss das erzeugte Thumbnail und der Eintrag in der DB gelöscht werden:

# Get the thumbnail path to remove the file from the filesystem
$ sqlite3 .xbmc/userdata/Database/Textures6.db "SELECT cachedurl FROM texture WHERE url = '/home/x/.xbmc/addons/my.lovely.addon/icon.png';"
6/6a643bff.png

Der Befehl

sqlite3 .xbmc/userdata/Database/Textures6.db "SELECT cachedurl FROM texture WHERE url = '/home/x/.xbmc/addons/my.lovely.addon/icon.png';"

gibt den Dateinamen des Thumbnail aus.

/home/x/.xbmc/userdata/Thumbnails/6/6a43bff.png

Nun muss der Link auch noch aus der DB gelöscht werden:

$ sqlite3 .xbmc/userdata/Database/Textures6.db "DELETE FROM texture WHERE url = '/home/x/.xbmc/addons/my.lovely.addon/icon.png';"

Wenn nun das Bild benötigt wird, wird das XBMC es neu erzeugen.
-------------

Weitere Infos dazu:
Wie das XBMC die Images erzeugt
PHP, Python, Java etc Codebeispiele

Vielleicht findet sich ja ein Addonprogrammierer, der damit was "basteln" kann...

So eine Art "Kill all related Images and DB-Entries"-Addon könnte ich mir vorstellen.
Bei Start eine Auswahl, was alles gelöscht werden soll.
Dann den Artikel auswählen und den "wenn weg dann weg"-Button klicken.

Keine Ahnung, ob man über ein Addon überhaupt so weit in die DB kommt.

Der Bedarf wird wahrscheinlich eher bei Medien als bei Skin-Images liegen.
Aber fang mal an.
Bin schon sehr gespannt aufs Testen dürfen

War zwei Tage nicht wirklich erreichbar... schreib ich morgen was zu.

Mit dem Daumen getippt...

Ein Bedarf für ein Addon könnte folgeden Situationen auslösen:

Thumbnailordner verkleinern:
Man will alle Arten von gecachten Bildern entfernen, die keinen Zusammenhang mehr mit der DB haben.
Somit könnte man den Thumbnailordner cleanen.

Ein bestimmtes Cover/Fanart von einem Film ändern:
Durch das bloße Ablegen eines neuen folder.jpg ändert das XBMC ja noch nicht das Cover.
Derzeit kann man natürlich das eine Cover dann manuell über "Info"-"Cover laden" ändern.
Wenn man aber das alte Cover endgültig killen will, müßte man es in den Thumbnails suchen.

Als Basisfunktion ist es bereits angedacht:

Zitat

The texture cache in the future will be auto-cleaning, i.e. textures that are stale will automatically be cleaned out to save disk space. Also, the music and video artwork will be moved to the new system. This will allow the cached versions of these images to be updated whenever the original image changes (eg you replace the fanart with a different version).

In addition, the texture cache will be updated to automatically tell the image control that it needs to refresh itself. Currently if the texturecache detects that a new version of an image is available (whether it be a .dds version or an updated copy of the original image that has since changed) then all that happens is the new version gets re-cached. Thus, you only see the new version of an image once you view it a second time after any change (this allows the image to be free'd from memory and reloaded from the freshly updated version).

Lastly, DXT5YCoCg is likely to be supported, as is further compression for the on-disk images in the form of lzo. If we do lzo compression then the cached versions will likely be 30-50% smaller, but ofcourse they will then be not loadable in any other software other than XBMC.

Steht in den Sternen... ist halt als "Feature Release" angedacht.
Da ab V12 ja die Images ohnehin anders behandelt werden (hat ja jeder schon gemerkt, der ein nightly getestet hat), könnte es schon mit der nächsten Version kommen.
Könnte...

Das ist richtig. Bei dem Addon sollte es ja auch noch zusätzlich darum gehen, gezielt etwas zu killen.
Vom Film Alien das Cover, die Fanart, das Logo, die Cd-Art, die Clear-Art... mit einem Klick löschen.
Sowas in der Art...