(2012-06-06, 15:54)tsubus Wrote: This is probably the cause of xbmcremote not showing any thumbs anymore, correct? What would need to change in their code to accomodate this change?
I've noticed that the userdata/Thumbnails/Video folders are all empty, seems like it's not caching anything at all. xbcmremote looks for .tbn files in there, and doesn't find any.
Correct.
"Thumbnails/Video":
* No longer used.
* Was previously the location for all thumbs (cover/posters), fan art and auto-generated content thumbnails for any videos.
"Thumbnails/Music":
* Still used when thumbnails are extracted from music files (i.e. mp3s with embedded cover art).
"Thumbnails/generated":
* Not used.
"Thumbnails":
* This is now where most images will be stored, with the new crc32(web URL to image) naming scheme. It is also the home for any custom images you installed from your local disk.
ALL your old Thumbnail data is completely useless so you might as well follow the advice in this thread and do a database export (to save the important library images to a backup folder) and then deleting the WHOLE Thumbnails folder and ALL Textures databases (see thread for info on doing this).
That will allow you to remove the junk that would otherwise remain from the old naming / organization scheme. If you don't do this, you'll have thousands of old thumbnails on the disk that will NEVER be used again yet take up anywhere from a few hundred megabytes to over a gigabyte, for no reason at all.
Also, when doing this, it's a good idea to carefully follow my advice about wiping and re-scanning your media library as well, so that you are guaranteed that the scraped image/art URL lists are up to date. The benefits of doing this is that you get the latest ratings, latest info, latest thumbnail/fanart lists, etc. The downside is that you lose metadata such as "watched" status, etc. It's up to you what to do.
The middle ground would be to wait for Martijn's script which will force a metadata refresh of any library items with invalid URLs, to get THOSE up to date.
There's no perfect solution anywhere, but I went for the "wipe library and start over" approach and am happy I did. Everything is now squeaky clean and up to date.
Edit: Just saw your second question; "What would need to change in the xbmcremote code to accomodate this change?" - answer: Some quite easy changes. Currently, they just take the crc32(/disk/path/to/video.mkv) approach to get a hash and look up the matching image in the Thumbnails folder. That's how XBMC used to do it, but that method can't be used anymore. They'll have to load the SQL databases for the libraries they're interested in (such as MyVideos.db), look at the video/movie/episode they're interested in to get the assigned thumbnail, then look up that thumbnail on disk.
(2012-06-06, 13:59)gabbott Wrote: (2012-06-06, 13:46)Basje Wrote: It's nice to see all the input and suggestions in this thread. I myself am wondering what this change will mean for those with a shared library and path substitution to a single thumb location.
Could somebody elaborate on that? What changes should we make to get this new system up and running correctly?
My understanding is that it negates the need for path substitution for video thumbs.
You will still need path substitution.
The difference is that there's no longer any relationship between the path to the video file and what thumbnail is assigned. This means that as long as the two XBMC libraries used the same web URL for their image, they'll both share the same thumbnail hash, regardless of whether the media path is /storage/media/movies/somemovie.avi or /mnt/NetworkDrive/movies/somemovie.avi. This means that there's no duplication of thumbnail data when moving files around or accessing them from different paths to the same file, since the hash is now based on the web URL and remains the same. That's one of the changes it brings. Less duplication of data. Another (even bigger) benefit is that when you're scrolling through lists of remote images, it's able to easily crc32() the URLs and see if a locally cached version already exists. Previously, when the thumbnails were named after the video filename hash, that wasn't possible; but now, with the URL-based hashes, it's easy to check if we already have a locally cached version of any URL we've previously downloaded, by simply hashing the desired URL and looking for that pre-cached filename in the Thumbnails folder.
However, to sync multiple libraries or share libraries, you'll still need <pathsubstitution> (
http://wiki.xbmc.org/index.php?title=Path_substitution) and thumbnail path sharing to ensure that paths are normalized across platforms, in order to actually be able to ACCESS the media that the library references. I.e. the local library might refer to /storage/movies/coolmovie.avi, and you're accessing that library over a network which can find that file at /mnt/netstorage/movies/coolmovie.avi; so you'd use a path substitution for your network client to be able to translate those local paths in the library to the relevant network-paths.
An even simpler, non-synced case that also benefits from these changes is when you're having two nearly independent XBMC installations. A local one and a networked one.
* Local one: has a thumbnail cache and has all the media on its own local disk.
* The networked one: uses <pathsubstitution> to replace "special://masterprofile/Thumbnails/" with a writable network path to the thumbnail cache folder of the XBMC installation above, as well as scanning all media from a shared folder on the network.
In this setup, they'd share thumbnail caches, meaning that they don't have to re-download thumbnails that the other has already downloaded. However, they'd be independent in all other ways and would not know about each others library data, actual thumbnail assignments, etc. All they'd do is share media files and thumbnail cache to save some time.
So, no, you still need pathsubstitution just as much as before, but there's now much less data duplication no matter how you look at it.