GNOME Bugzilla – Bug 583130
Cover art caches too much
Last modified: 2009-12-05 21:27:39 UTC
The ArtworkManager caches artwork in too many cases. It probably shouldn't cache artwork that is used for the TrackInfoDisplay, since a) they come infrequently, only one every couple minutes usually b) the TrackInfoDisplays can be many different sizes (eg in Now Playing, can be nearly any size) It should probably only cache images used in the ListView (eg the Album browser), since scaling those on the fly is too slow. To be clear, here are some (not even all) of the folders I have in ~/.cache/album-art, most of which only contain a few scaled images: 101 106 107 111 113 114 115 117 121 123 128 129 130 131 132 136 138 140 142 143 144 146 149 150 151 152 153 155
One way to fix this could be to have a method on the ArtworkManager like this: artwork_manager.AddCachedSize (48); And the Album ListView can actually be responsible for calling this method, since it is what knows it needs the fast-access to scaled images.
Created attachment 149009 [details] [review] Cache for the common sizes Only cache when the size is "whitelisted". Initially, sizes used by core are whitelisted, and then some extensions (Last.fm, NotificationArea, Moblin) add some more as needed. Also, whitelisted sizes can be read, in order to unblock bug #336350
Comment on attachment 149009 [details] [review] Cache for the common sizes I think this is an important area for Banshee to improve on, so I'm going to commit your patch to a new, public branch: art-caching. I still think we are allowing caching of too many sizes: 36, 40 (last.fm), 42 (notification area), 48, 64, 98 (moblin), 300
I agree - the white list of cache sizes is a good step. Additionally, I had wanted to introduce a simple sqlite database of cached artwork such that it can be quickly loaded and converted into an LRU cache. As some worker task, the items in the database that are old enough would be removed from disk. There's concern on the embedded/mobile space that the artwork cache, regardless of white-listed cache sizes, can grow too large. I would also like to make an addition to the white list patch: add a debug call when something is /not/ going to be cached. This debug output should also list the available cached sizes, to make it obvious that it might be optimal to request a different size.
I've pushed a debugging line like that (bug doesn't have the list of available sizes yet) to the branch. I also pushed some other optimizations, and some migration code that will delete all the no-longer-cached sizes' directories.
The directory-deletion migration code won't play nicely with extensions that add their size to the cache list, though. I added the sizes that were added that way to the ArtworkManager ctor for now.
Thanks Félix, this is fixed in master now.