Registered Member
|
Hi, I've an iPod classic 80Gb. I synchronized it with Amarok (Kubuntu 7.10) but I've a problem with the artwork: the iPod is really slow to read the artwork when I use the "Coverflow" or I just open an Album. The strange thing is the dir /media/IPOD/iPod_Controlo/artwork because is 3 gb big. I've about 800 album and it should be around 200 Mb. Does anyone know what's the problem and how to solve it?
Thanks. |
Registered Member
|
WOW I will have to check mine...how do you know how big it "should" be? by the original file sizes combined?
|
Registered Member
|
Each artwork is around 200Kb. 800 albums means no more than 150Mb. If the Artwork directory in the ipod is 3Gb i suppose there's something wrong. The ipod is really slow charghing the covers maybe because there are 3Gb of artworks. Does anybody know how can I solve the problem?
|
Registered Member
|
|
Registered Member
|
I have the same problem then yours. My artwork file was 12Gb big ! It seems like an amarok bug, isn't it ?
I have to rebuild my ipod files with gtkpod and reload all my music with amarok then. Did you find a solution ? |
Registered Member
|
Not yet, and now I've another problem: after the upgrade of the ipod's firmware amarok isn't ably anymore to upload songs on my ipod. Does anybody have the same problem?
|
Registered Member
|
I've got this problem as well - version 1.4.9.1 under Ubuntu 8.04 using an iPod Classic 80Gb.
I have 8200 tracks synced with the iPod totally using Amarok (I initialized it with Amarok too after deleting all content when moving from WIndows to Ubuntu), but I now have a HUGE artwork folder - 2.6Gb - way more than when I sync with iTunes on Windows. Coverflow is VERY slow, only ever displaying covers that are immediately in view on the screen, and hanging to load more as you scroll through. Viewing a list of albums by any given artist also causes the iPod to hang whilst it loads the album covers. If you exit CoverFlow and then return to it later (without rebooting the iPod) it's all blank again, and hangs to load artwork each time... Does anyone have any help on this? Amarok is the only thing that I've found that comes close to being able to use my iPod with Linux efficiently. I've tried Floola, but it's just far too unstable, frequently causing the database to corrupt, and then all the artwork to go missing, requiring a rebuild which is tedious. Gtkpod is just way too slow to use practically with such a large number of tracks... it also reads my tags incorrectly for my local database, which stuffs up the tracks' data on the iPod. Apart from this artwork problem there isn't much I can complain about with Amarok (except that setting tracks to "Various Artists" doesn't have the same effect as turning on the "compilations: Yes" tag in iTunes, but that's small potatoes compared to this very annoying artwork problem... |
KDE Developer
|
I think that is an issue of the libgpod library that shows up if Amarok sets the cover image for a song a second time, e.g. when updating artwork. It would be great if you could investigate on this and report your findings to the gtkpod-devel mailing list.
|
Registered Member
|
Well, I've just done some testing - I reinitialized the iPod by wiping Artwork, iTunes and Music from the iPodControl folder, and let Amarok rebuild it.
I added 1 album only consisting of 12 tracks (with cover art measuring 200x179px - 13kb). The resulting files in the Artwork folder amounted to 3.9Mb! 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 So, I tried duplicating this by using gtkpod - again wiping the iPodControl folders...exactly the same thing... I tried with both the stable version 0.6.0 of libgpod, and also the latest CVS trunk version (renaming the old library, and linking in the new one). Exactly the same with both versions. It's obviously not a problem created when you add files on subsequent occasions, it's there from the outset... It also affects the iPod no matter whether the artwork is embedded in the MP3s or if it is just picked up as a folder.jpg by Amarok... I'll probably cross-post this across to the libgpod-devel guys if no-one can offer any other ideas here...
Last edited by Rod Hull on Tue May 06, 2008 6:27 pm, edited 1 time in total.
|
Registered Member
|
I've been doing some more tests, and I added the exact same single album from before using iTunes on Windows to my iPod Classic 80Gb.
Here's the dir listing from the iPodControl/Artwork folder now: drwx------ 2 xxx root 16K 2008-05-08 09:44 . drwx------ 8 xxx root 16K 2008-05-08 09:44 .. -rwx------ 1 xxx root 2.6K 2008-05-08 10:18 ArtworkDB -rwx------ 1 xxx root 64K 2008-05-08 10:18 F1055_1.ithmb -rwx------ 1 xxx root 400K 2008-05-08 10:18 F1060_1.ithmb -rwx------ 1 xxx root 13K 2008-05-08 10:18 F1061_1.ithmb A much more respectable 512kb in total. As you can see, there are two fewer files created by iTunes than by libgpod (F1028_1.ithmb and F1029_1.ithmb are missing with iTunes). This has no detrimental effect on the artwork. It still displays in iTunes, in coverflow on the iPod, and in the album-list on the iPod, and the Now Playing screen... Also, the filesizes of the files that are shared between each system are vastly different...It seems that the files created by libgpod are approx. six times the sizes of those created by iTunes... Libgpod is obviously doing something wrong! Could anyone comment at all or offer any help on this? |
Registered Member
|
I have the same issue, I have a 1.2GB files with just about 200 albums with cover. Coverflow is also very slow.
Thanks! |
Registered Member
|
How slow is slow? I have about 2000 songs on my 80GB Classic (about 200 albums I guess) and it takes 2 to 3 seconds for the artwork to appear in coverflow. However this is about the same time as it takes a track to start playing, so I was assuming it was just the hard drive access speed. I've only got about a quarter of my music loaded, so I don't want it to get much slower. Regarding the database size, and this is pure speculation on my part, maybe libgpod is not compressing the artwork. I've no idea what colour depth libgpod is using but a 200x179 1024 colour image would be about 4.5 MByte, which is approximately what people are seeing. Perhaps ITunes uses a proprietory compression algorithm that the linux libraries don't want to infringe. As I said, this is pure speculation and it could be something else entirely. The libgpod homepage admits that the artwork functions need a bit of work. |
Registered Member
|
Slow is ~2-3 seconds to load the initial view of coverflow, but as soon as you scroll beyond what has been loaded (which is normally only ~10 covers or so) it pauses again to load more - this happens each time you move beyond what is currently displayed on the screen. It basically renders coverflow useless IMO.
I've posted this on the gtkpod-devel list, and 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. It must be able to reuse this information somehow since everything looks fine on the iPod - I can play one of the tracks that doesn't explictly have artwork attached and it displays it correctly. The two files that libgpod adds that iTunes doesn't (F1028_1.ithmb and F1029_1.ithmb) can be removed from the iPod without any significant loss to any stored artwork..it doesn't improve performance much, however - coverflow still exhibits these long pauses and stutters...
Last edited by Rod Hull on Mon May 12, 2008 2:14 pm, edited 1 time in total.
|
Registered Member
|
It's fixed!
Due to some of my e-mails to the gtkpod-devel list and further testing by myself and the devs, this has been fixed in the latest SVN of libgpod! Just install it, replacing the stable version, and adding music with Amarok now performs in the same way as with iTunes, using sparse artwork. For my 50Gb collection, I only have ~160Mb of artwork! Coverflow is now working properly again! Kudos to the libgpod devs! |
Registered Member
|
That's real good news. Now, all i need is for them to release the final version (0.7.0 I guess?) and for Fedora and Debian (the distros I use) to add it to their repositories...How long may that take?
Regards. |
Registered users: Bing [Bot], Google [Bot], Sogou [Bot], Yahoo [Bot]