Why to Upgrade to Libgpod SVN Build

I didnt pay much attention to the iPod artwork issue until I found the coverflow became extremely slow and out of response occasionally.

I’m using Amarok via libgpod-0.6.0 to manage my iPod library, there’re approximately 1,000 songs of 68 albums in my iPod. As I checked the iPod_Control/Artwork directory of my iPod, it took up unexpectedly +300mb for the cover images.

punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/
314M    Artwork/

Then I tried iTunes to rebuild my music library, the artwork database shrinks to 53mb.

punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/
53M     Artwork/

As someone in that post pointed out:

it turns out that iTunes isn’t actually storing one piece of artwork per track or even one per album - in my case at least, it stored one cover for only 2 of the tracks on the 12-track album …

Fortunately this issue has been fixed in the libgpod svn version, and the new artwork database size looks quite impressive. It’s even smaller than the iTunes’ one.

punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/
18M     Artwork/

The latest libgpod svn build has already supported the new iPod Nano 4G, and the photo issue also seems to be fixed. If you dont have the patience for a “never-landed” new stable release, grab the latest libgpod svn snapshot.

For Gentoo users, you may put the media-libs/libgpod-9999.ebuild into your personal ebuild repo.

Note : I removed the doc USE flag from the ebuild due to the latest libgpod somehow needs gtk-doc to make distcheck to work correctly. Bad news, KDE fan boys :(