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. Regarding the database size, and this is pure speculation on my part, maybe libgpod is not compressing the artwork. I've only got about a quarter of my music loaded, so I don't want it to get much slower. 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 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. Libgpod is obviously doing something wrong!Ĭould anyone comment at all or offer any help on this? six times the sizes of those created by iTunes. It still displays in iTunes, in coverflow on the iPod, and in the album-list on the iPod, and the Now Playing screen.Īlso, the filesizes of the files that are shared between each system are vastly different.It seems that the files created by libgpod are approx. This has no detrimental effect on the artwork. rwx- 1 xxx root 13K 10:18 F1061_1.ithmbĪs 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). Here's the dir listing from the iPodControl/Artwork folder now: 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. I'll probably cross-post this across to the libgpod-devel guys if no-one can offer any other ideas here. 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. It's obviously not a problem created when you add files on subsequent occasions, it's there from the outset. 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). So, I tried duplicating this by using gtkpod - again wiping the iPodControl folders.exactly the same thing. The resulting files in the Artwork folder amounted to 3.9Mb! I added 1 album only consisting of 12 tracks (with cover art measuring 200x179px - 13kb). 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. it also reads my tags incorrectly for my local database, which stuffs up the tracks' data on the iPod.Īpart 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. Gtkpod is just way too slow to use practically with such a large number of tracks. 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. 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.Īmarok is the only thing that I've found that comes close to being able to use my iPod with Linux efficiently. Viewing a list of albums by any given artist also causes the iPod to hang whilst it loads the album covers. 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.Ĭoverflow is VERY slow, only ever displaying covers that are immediately in view on the screen, and hanging to load more as you scroll through. I've got this problem as well - version 1.4.9.1 under Ubuntu 8.04 using an iPod Classic 80Gb.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |