[john.doe]

well keeping watched data worked for me the last time with settings source to none and back to movies again

That's strange; maybe that is stored in the "files" table then rather than the "movies" table. As I mentioned above, the files table is not cleared when clearing the library; only the movie and tvshow tables are affected. So I guess that the scanner re-adds the movies and XBMC re-matches them to their "files" table counterparts.

Interesting if that is the case...

[Basje]

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?

[gabbott]

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.

[tsubus]

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.

[john.doe]

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.

---

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.

[tsubus]

Thanks for the clarification, makes much more sense now. I might look into xbmcremote to accomodate it to the new format.

One more question that I have doubts about: if I have thumbnails generated outside of XBMC (from Sickbeard, for instance) inside the TV Show/Season/Episode folder, would those thumbnails still be read by XBMC or would it always download new art from the Internet?

[john.doe]

Thanks for the clarification, makes much more sense now. I might look into xbmcremote to accomodate it to the new format.

That would be nice of you, but probably more work than you think. Unless you already know their codebase and how they interface with databases and all relevant fields, etc, you'll just be wasting a day of your time and hit a brick wall somewhere. Only proceed if you feel like learning their codebase.

One more question that I have doubts about: if I have thumbnails generated outside of XBMC (from Sickbeard, for instance) inside the TV Show/Season/Episode folder, would those thumbnails still be read by XBMC or would it always download new art from the Internet?

All artwork placed directly within the movie/show/season/episode/whatever folder always takes precedence over any available internet images during library import, but you'll have to do a library clear and re-import to get your local art files to be picked up by XBMC again, because last time they were imported by XBMC they were copied to the "Thumbnails/Videos/" folder using the old-style hashing, so a re-import is now needed to get them to be stored in the new way (which is far more complex, involving database entries that map media to thumbnail names, so a full re-import is the only way to get this data written).

[jmarshall]

IIRC the bookmarks table is cleared. But yes, watched information is kept, as is per-video settings.

[jmarshall]

@tsubus: xbmcremote simply has to use the API in the correct way. If they are doing things completely correctly, then it SHOULD still work - i.e. the thumb paths should be something like image://<url_encoded_path_to_real_image_url>, and if they use the vfs of the JSON-RPC to access those images then it should work just fine. My guess is it's HTTP-API, thus it's broke (HTTP-API is effectively depracated with Eden, it'll be completely gone in Frodo). The iOS remote works fine without any changes as it's using the JSON-RPC api.

Further, if you have local images next to your media files, then there's no need to do anything - the backward compatibility will recache the art automatically without going to the web - we go to the web only if no local images exist. Only if the local art is elsewhere and you set the art via the Get Thumb/Get Fanart -> Browse item will you need to redo it.

@gabbott/Basje: This negates the need for thumbnails being shared via pathsubstitution. Each client keeps it's own cache, so if you use pathsubstitution all you're doing is causing things to go significantly slower, as the images are no longer local. Do not use pathsubstitution for anything except music thumbnails now (just path subs the Music subfolder).

Each client will then cache the art locally for fast access. You can safely copy the Textures13.db and the thumbnails folder from client to client if you wish to speed the process up - personally I find things cache fast enough that it isn't worth the hassle.

Cheers,
Jonathan

[gabbott]

@jmarshall: thanks, that's how I understood it.

@John.doe: I was referring to the need for it specifically for video thumbnails. Your explanation of still needing path substitution is if all media shares aren't in the same location in reference to each client. I have a media server so every client's path to the shares is identical.

[Basje]

@jmarshall Thanks for the info. Looking forward to ATV2 builds. Is there an ETA for them to be back up again.

[jmarshall]

Nope - IIRC it's the ffmpeg issue that's stopping 'em. There's more info available in other threads.

[Hitcher]

Thought I'd give this a try out on my Revo 3700 using a nightly OpenELEC build to see how it compares against DDS fanart but, at the moment at least, it's just not as fast.

While this improve in time?

Thanks.

[jmarshall]

This does not negate the use of DDS fanart - you can still have it on top. Loading time, nonetheless, will likely improve once the resizing stuff is in - atm we're caching at fullsize which is hardly ever required in the UI.

[Hitcher]

Thanks for the quick reply.