AFAIK GDresizer does all the little artwork like eg. cover_96x96_p.png
Right, but I thought everything was pre-cached at scan time. Even if
No, it's not: only sizes which are expected to be used often, very
likely, and lots at the same time are pre-cached. That's mostly the
smaller sizes used in browse modes, where the UIs would often require
them by the dozens, or hundreds at the same time. But eg. the size shown
on the device's Now Playing screen is not pre-cached, as this is a
single image only, and you'd hardly ever need all of them.
Now there's a twist to this which can have a massive influence on the
artwork.db file cache: applications or plugins can register their own
sizes to be pre-cached. Eg. iPeng does this. Therefore the size of your
cache file depends on your use of 3rd party tools, too. You can find
those additional sizes in Settings/Advanced/Performance.
some of the sizes aren't precached, if the same original images are
being handled later, you'd think GDresizer wouldn't have a problem with
them.
That's true.
Is there a debugging flag that could be turned on to better tell what's
causing the crash?
artwork
--
Michael
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
