[Gtkpod-devel] Very large Artwork folder with very slow Coverflow

[Rod H. <iwa...@go...>]

I've been testing out both Amarok version 1.4.9.1 and also gtkpod 
0.99.12 under Ubuntu 8.04 using an iPod Classic 80Gb. The behaviour I'm 
about to describe happens both with the stable 0.6.0 and latest CVS 
version of the libgpod library.

Whenever mp3s with artwork are added to the iPod, the resulting Artwork 
folder under iPodControl becomes ridiculously inflated.

For example, in my case with 8200 tracks (~47Gb worth of mp3, with all 
albums having cover art), the artwork folder is a crazy 2.6Gb in size.

Coverflow is VERY slow, only ever displaying covers that are immediately 
in view on the screen, and pauses to load more as you scroll through. 
Viewing a list of albums by any given artist also causes the iPod to 
hang way longer than it should whilst it loads the album covers. If you 
exit Coverflow and then return to it later (without rebooting the iPod) 
everything's all blank again, and again it pauses heavily whilst loading 
artwork each time...

This happens with a totally blank iPod formatted by iTunes in Windows 
with firmware 1.1.1 and 1.1.2

I ran some further tests by wiping the iPod and adding ONLY ONE album 
containing 12 tracks with cover art (a 200x179px jpeg with a filesize of 
13kb).

I did this from scratch in both gtkpod and Amarok, reinitializing the 
iPod each time and also trying both 0.6.0 and the latest CVS of the 
libgpod library...

The resulting Artwork folder was a disproportionate 3.9Mb in size after 
only one album having been added:

drwx------ 2 xxx root  16K 2008-05-06 19:07 .
drwx------ 7 xxx root  16K 2008-05-06 19:07 ..
-rwx------ 1 xxx root  13K 2008-05-06 19:07 ArtworkDB
-rwx------ 1 xxx root 235K 2008-05-06 19:07 F1028_1.ithmb
-rwx------ 1 xxx root 938K 2008-05-06 19:07 F1029_1.ithmb
-rwx------ 1 xxx root 384K 2008-05-06 19:07 F1055_1.ithmb
-rwx------ 1 xxx root 2.4M 2008-05-06 19:07 F1060_1.ithmb
-rwx------ 1 xxx root  74K 2008-05-06 19:07 F1061_1.ithmb

It doesn't seem to matter whether the artwork is embedded in the mp3s or 
whether whichever program used to sync has picked the jpg from Amazon, 
or from an already existing folder.jpg

Can anyone offer any hints as to why this happens, or a possible 
fix/workaround?

At the moment this behaviour renders coverflow virtually useless, and 
causes the iPod to lose a disproportionate amount of disk storage to the 
huge Artwork folder...

Thanks...