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

[Peter <rhythmbox-devel maubp freeserve co uk>]

On Wed, Jun 13, 2012 at 10:26 AM, Hanno Zulla <abos hanno de> 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