http://bugs.gpodder.org/show_bug.cgi?id=235
--- Comment #5 from flow <[EMAIL PROTECTED]> 2008-11-01 13:30:24 --- Well, here are my findings: 1. rebuild-db creates some kind of a second database on the pod, the original one remains untouched, but is not used by the iPod anymore(don't ask me how the author gets this to work, I'm not so much in the topic :) ). So changes made by the script are not visible to gtkpod, gPodder, Rhythmbox, etc. 2. it is possible to work around all the shuffling and sorting algorithms. However, the order of the second (rebuild-db) database is still (very) different from the original one. As far is I could figure it out, the script searches recursively for files matching the in-built or customly defined rules without any noticable order (at least for the some attempts I made) except that files already stored in one folder (e.g. in IPOD/iPod_Control/Music/f04) stay together in the playlist. So this is not really handy, because one would have to implemente a custom sorting mechanism to make this work properly. Moreover, you'd exclude other management software from using the pod properly. Maybe it is a problem of python-gpod (consequently also libgpod) and how it's used, because libgpod is the basis of gtkpod, which successfully builds a proper database. So a look at their source might be interesting. -- Configure bugmail: http://bugs.gpodder.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ gPodder-Bugs mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-bugs
