Re: [Rhythmbox-devel] Q: Why cache embedded album art in ~/.cache/rhythmbox/album-art?

[Hanno Zulla <abos hanno de>]

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, 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.

Thanks!

Hanno