Quote:If you create a smartplaylist with the entire movie or tv show library, when you enter that, it still does the total duration calculation, however, the artwork for the currently selected item is displayed before the duration calculation (correct behavior)
But when you enter the actual library, the artwork for the currently selected item does not get displayed until the duration calculation is completed. And it can take a long time if you have a large library 1000+ movies and also if you're on wifi.
I'm not sure how this can be, as the exact same code is being run in both cases. To rule out things that may not be obvious, try starting XBMC from scratch and going into movies. Then start from scratch and go into the smartplaylist. The behaviour should be identical.
The counting of duration has nothing to do with this, though it _appears_ as though it does. The logic is as follows:
1. Run through a list of items. For each item:
2. Fetch stream details if already in the db (db lookup per item).
3. Fetch thumb details if already in the db (db lookup per item).
4. Check for missing art on disk if not available (only if 3 returns no results).
5. Calculate stream details if not available.
6. Move onto the next item.
The actual loading of art is done in a separate thread, so can potentially occur directly after step 3 of the first item in the list - there's no need for it to get all the way to the end of the list, except for the last item in the list (this is why if you go directly into a list to the last item it takes longer for the art to show up).
In addition, several other things might slow it down - the processing through the list and access to the db is reasonably IO heavy, and so is loading a .jpg off disk, so is loading other images associated with the items and so on. If you are using mysql over a high latency connection, then those db queries are going to be quite slow so this will be made quite a bit worse. And most obviously, if art hasn't yet been cached, it will take quite a bit longer. The same if stream details have not yet been computed. This is a one-off though.
As always, there's some ways that could improve it. For a start, we should do steps 1-3 in a separate loop from steps 4-5, as that's fetching all the stuff that's already available, which should be much quicker. That way, should steps 4 and 5 be stuck on an item that doesn't exist or something the rest of the process doesn't get held up. This sounds easy, but isn't due to the way things are setup - needs a bit of refactoring to do it nicely which I just didn't have time for pre-Frodo.
Lastly, Eden _appeared_ faster due to several reasons:
1. Art was done synchronously - you didn't get the list back until the art was already set on it. (i.e. the list appeared slower, but when it appeared all art was already set on the items, so just needed loading off disk).
2. A single piece of art was available per item (or two if fanart was included). Frodo includes arbitrary amounts of art.
3. No db queries were required due to step 2 - instead a stat() of the local filesystem was enough. This also lead to know way at all to know where the cached art came from, thus no auto-updating art, no record of the source of art and no way to clean art out properly after the fact.
Cheers,
Jonathan
