On Wed, Jun 13, 2012 at 10:26 AM, Hanno Zulla <[email protected]> wrote: > Hi, > > thanks for the response! > >> It does waste a little space, but the caching is done at the album level >> so not so much. The main advantage is for rapid cover display there >> is just one place to look - and loading an image file is simpler than >> loading an image from a music file (which may be on a different file >> system). > > This is a large collection of MP3 music, stored on the local file system > of the computer. > > I'm still not sure that the album cover cache is really necessary. Why > keep a copy of the full, non-resized album cover image? (Even a slow > Sonos CR100 remote is fast enough to show resized album art while > browsing the album list from a remote file share on a slow network > connection. AFAIK the CR100 has no persistent local image cache.) > > When playing the album, RB needs to read the MP3 tags anyway and can > fetch the album cover. Same is true for iPod sync. Right now, RB looks > at the cache dir content instead of the very music file that RB is > reading at the same time. > > What is the reason RB needs rapid cover display? There is no cover > browser in the default distribution, only via an optional plugin, right? > If that wanted to save time on displaying cover thumbnails, why not use > ~/.thumbnails/ instead and put temporary copies of resized copies of the > album covers there?
Also browsing from another device - e.g. sharing music, then it may have to provide many covers (and not just for the currently playing track). >>> Also, it doesn't seem to work right all the time. I didn't debug this, >>> so the following observation could be mistaken, but it seems to me that >>> when I play a new album for the first time, the cover art will only >>> appear _after_ playing the first track. Why is this so? >> >> That could be a bug - you'd need to explore where the image came >> from (online search, embedded in the music files, local hard drive >> next to the music file, etc). > > I'm talking about albums on the local hard drive, with embedded cover > images as MP3 tags. Comparing the cached cover art and the image > embedded in the MP3 file, they have the same size and same MD5 > checksum. > > Again, I didn't debug this at source level. Guessing here, but it > *looks* to me that when playing an album for the first time, RB looks at > the first track's album cover during playback and caches but does not > display it, so that the cover is "available" to RB once it starts > playing the second track. That sounds very possible - I've not looked at the code for this for a while. Peter _______________________________________________ rhythmbox-devel mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rhythmbox-devel
