[Raytestrak]

I think xbmc should cleanup after itself more. The Pi is one example of a potentially low storage device, but xbmc for android is coming out too. If you have a 4GB android TV stick (which may or may not run xbmc, but for arguments sake, let's say it will), you don't want all the leftovers. For example: when you delete an item, the artwork remains. When you change fanart, (or banners or covers) the old one remains.

Personally, I would like xbmc to handle this better. I don't know if this would help performance too. I've stopped using the music database because I had well over 20.000 thumbs in my cache. I Always image myself searching in box of legos trying to find the right piece, more pieces means more searching But I'm not a computer so I'm not efficient in anything I do.

[jmarshall]

@Raytesrak: The information is in the textures database. You're welcome to query it and come up with a small script to clean it up.

[Raytestrak]

@Raytesrak: The information is in the textures database. You're welcome to query it and come up with a small script to clean it up.

I'll try, but how much trouble would it be to automatically delete everything related to media that's been deleted? Or when you change fanart, why does it make a new entry instead of overwriting the existing one? I'm just trying to understand the logic behind it.

[Ned Scott]

Keep in mind, if you only have a small amount of memory, like on an Android device or an ATV2, you can still use pathsubs to share/move thumbnail storage itself. Same with Symbolic links and dropbox solutions. This is better default behavior, but doesn't remove other solutions.

[kolja]

Keep in mind, if you only have a small amount of memory, like on an Android device or an ATV2, you can still use pathsubs to share/move thumbnail storage itself. Same with Symbolic links and dropbox solutions. This is better default behavior, but doesn't remove other solutions.

If I understand correctly what was said in this thread and what is outlined in the wiki, the new behavior _will_ break current solutions, because of the way how the TexturesDB is integrated into the process.

When I share the Thumbnails folder between clients, each client will still have its own TexturesDB. The decision whether an artwork is available in the cache or must be downloaded is not based on the presence of a file in the Thumbnails folder, but on the presence of an entry in that database. Each client will download that artwork again and overwrite the file already present in the shared cache.

It would be necessary to share that database too, and because shared access to a sqlite database file is not an option, we would need an option to move it to the mysql server via advancedsettings.

[jmarshall]

I'm just trying to understand the logic behind it.

Then load up the database and take a look. If you delete a movie, that does not necessarily mean that the art is useless. Often movie deletions occur via refreshing an item, where you don't want to delete the art at all as it's unlikely to change.

Either way, the textures database is there so it can provide a way to automatically clean things up - load it up and take a look.

[bradvido88]

#1 In a synchronized (MySQL) setup, will there be any problems (as kolja suggested) since the Textures sqlite db is not synchronized between clients?

#2 Why does the wiki state that centralized sharing of thumbnails will "slow things down in Frodo"? What's the technical reason we shouldn't synchronize (symlink or path substitution) the Thumbnails in a central place on Frodo? Is it just network lag?

For me, it works better because the centralized thumbnails only need to be cached (and converted to dds) once and are then immediately available to my 5 lightweight XBMC clients (no noticeable delay over gigabit LAN). My clients all PXE boot anyway, so local caching is certainly not faster than a network share since they don't even have hard drives..

[Ned Scott]

Testures db stores info about the cached files themselves, but the url for the images to be downloaded are stored in the video db.

I'm not really sure on the full technical details, but it's very possible that it won't make a difference in a PXE/network boot situation. Even with local drives, sometimes the slowdown isn't that noticeable, but other times it can make a big impact. It's not just a technical viewpoint either, since we've had people post about the slow down on the forums before.

[kolja]

I know that the URL is in the (possibly centralized) _video_ DB. But as I already said, the decision whether that URL needs to be downloaded or can be taken from the cache depends on the presence of an corresponding entry in the _textures_ DB, at least according to [1]. And if that DB can't be centralized too, each client will download again, so a shared Thumbnails directory won't be of any use anymore.

[1] http://wiki.xbmc.org/index.php?title=Thumbnails/Cache

[Ned Scott]

A shared thumbnail directory will still be of use for anyone who is using one to save file space on a device with limited internal memory. Other than that, the download (or attempt to download) will only happen once. If it's an issue to download again from the internet, one can always use the export option in XBMC to place the images along side the media (after the first client has downloaded them), and the other XBMC clients will load the local images instead of looking for them on the internet (the reason this doesn't really work in v11 is because v11 has no way to check /refresh missing thumbnails, local or not. It just looks at it as if there is no thumb having been set).

[kolja]

A shared thumbnail directory will still be of use for anyone who is using one to save file space on a device with limited internal memory.

No, not entirely correct. Such a client will profit from _moving_ the Thumbnails dir to a server to save space on the local filesystem. But there is no more use in _sharing_ the same dir on the server with other clients to avoid multiple downloads, because each client will download the artwork once again.

Why not just provide the option to share the TexturesDB too by moving it to mysql?

[Ned Scott]

Well, I imagine situations where more than one device has low memory (multiple R-Pis or ATV2s in each bedroom, for example), but yes, I should have said "a path sub'ed thumbnail directory" instead of a "shared" directory. Though technically speaking, the two are the same in this case (you have to use a file share to move the thumb directory off the original machine) even with just one XBMC box.

As for not moving textures db to mysql, I don't know. What that would take and what it would impact is over my head. I do know that MySQL in general is seen as a dead-end for library sharing, and the Team is more focused on supporting efforts to improve UPnP sharing to replace MySQL.

[bradvido88]

If you want to go against recommendations, I have had success sharing the sqlite db's

This would prevent the one-time re-download/overwrite to cache thumbs on each client.

[bilbonvidia]

Hi I have just installed frodo on one of my machines. I have previously been using a shared thumbnail folder via path substitution, how should I now proceed. Is it best to take out the path subs from advanced settings. I will be upgrading all of my machines in due course once I figure out why I have no sound and why I am getting v low fps.

[PH-SYM]

As bilbonvidia said, I would like to know this as well. Is it better to remove the path substitutions from advanced settings or not?