Attention: Thumbnail cache rewrite's unintended consequences

I'm not sure is this exactly the way it's supposed to work or if something is amiss, but sometimes the behavior seems odd. I originally had a central thumbnail folder on my NAS so when I switched to a Frodo build and started using the new Thumbs cache, I had to either refresh all movie and TV show thumbs or scroll through them all slowly to allow the thumbs to load. Once I did this, I can scroll through my lists lightning fast and the thumbs show right up. The problem is that if I reboot the machine they are slow to display again the first time. Granted, not as slow as that initial time through them, but maybe taking 2-3 seconds to appear. Once I go through them all again, they load really fast again. Sometimes some of the thumbs are much slower to load. Last night, after a reboot, I went into my unwatched movies which is about 35 movies and I use wall view like in Confluence. When I first went into that view, most loaded in 2-3 seconds, but the last 12 or so took over 20 seconds to load. I never experienced anything that slow when I was using shared thumbs from my NAS. Is there any way to avoid any of this or is some/all of this to be expected?

Don't share thumbs, you're just slowing it down.

I'm sorry I wasn't more clear. I am not sharing thumbs. I was until I saw this thread and read that this was enabled in the Frodo builds. I then switched to the new thumb cache and removed the <pathsubstitution> related to sharing thumbs from my advancedsettings.xml on al machines. The issues I'm speaking of are while using a local thumb cache.

(2012-06-27 22:20)jmarshall Wrote:  Don't share thumbs, you're just slowing it down.

what's the proper setup for a frodo based share then?

NO path substitutions in advancedsettings.xml? OR just sources.xml

No path substitutions for video thumbs. None for music thumbs once my PR is pulled in (probably today).

You don't normally need any path substitutions for anything else, right?

Hmmm. I'm still having issues with thumbnails pulling on separate machines.

Update: Music thumbs are done and are in now. No doubt there'll be a bunch of issues that I haven't been able to test

(2012-07-05 01:29)jmarshall Wrote:  Update: Music thumbs are done and are in now. No doubt there'll be a bunch of issues that I haven't been able to test

Going to test this tomorrow. I have "smallish" music library just waiting for this (I'm usually using Spotify addon for my music needs) that has not ever been scanned to XBMC's library.

Dumb question: Should we expect somewhat similar behaviour what we have now with video library, when using MySQL database and multiple XBMC clients? Like: "One computer does scanning, pulls artwork to local cache and puts a bunch of urls to DB. When another computer (XBMC client) browses Music Library, it pulls the same art from DB stored urls to local cache if they are missing or changed.."

Yes. Note that with music art, as we have to consider embedded art, a rescan is required for album art to show up. I'm not sure if this is possible as things are without blowing away the db.

I'll be working on getting a prompt in the UI on first access of music to initiate this - note that it's just the tags that need rescanning - no need to rescan additional online artist or album info. It'll take a couple of days to get it up and running.

Cheers,
Jonathan

Jonathan, until the resizing code is in mainline, will it work doing a batch downsize on the thumbnails folder for low power machines? Or will changes be needed in textures.db as well?