On Wed, Sep 01, 2010 at 10:35:34AM +0200, ilf wrote: > On 07-27 16:34, Christophe Fergeau wrote: >>> Do you know of any other Free Software tools running on GNU/Linux, >>> that make the device work, until this is implemented in GNUpod? >> libgpod got support for it in git, it should be available in the next >> release (0.7.94). > > libgpod 0.7.94 has just been released: > http://sourceforge.net/projects/gtkpod/files/libgpod/libgpod-0.7.9x/libgpod-0.7.94.tar.gz/download > > Any chance we can see this in gnupod, too? >
Well, seeing that I've /scratched my itch/ by extending gnupod_addsong's capabilities in regard to podcasts, and by writing gnupod_find and gnupod_delete, I've let gnupod sleep for quite a while ... I guess I'll have to write at least gnupod_modify to complete that tool set and get 1.0.0 out there before there are no ipod left that gnupod still works with :-/ I'd love to do the 3gen shuffle and the sqlite based new ipods but I think the code that produces those ipod-readable files needs some serious refactoring or maybe even a full rewrite first. Right now extending gnupod at those parts would (at least for me) be a royal pain. What I'd love to do is a modular rewrite where mktunes.pl (the script that (SAX-)parses gnupod's xml files and produces the ipod-readable files) produces the output files according to the ipod-model chosen. Here are some thoughts I had so far: The output files should each be generated by a specialized writer object that gets instanciated at the start of mktunes.pl. Naturally there is no need to instanciate a writer object for one of the new sqlite based file formats when the device in question is a 3gen nano. On instanciation the writer registers itself for certain tags. I.E. the writer for a 1.gen shuffle would register itself for "file" and "playlist" but not for "smartplaylist". Then mktunes runs a SAX parser and when a tag is read, the parser calls all registered writer objects' methods for processing that kind of tag. Some information collected while reading the "file" records is needed later when processing the "playlist" records. So we need those writer objects to preserve some state. Also there are some fields in the beginning of the output file who's value can only be computed after reading the whole shebang. A writer needs to remember the positions within the file for those fields and it needs to seek to those positions and write that data when encountering the closing gnuPod tag. The extended playlists (not the smartplaylists) are a bit of a pain here. They imply that I either keep all "files" data in memory or that I parse the xml file twice so that I know during the second run, which "file"'s IDs to keep for the extended playlists. Maybe that feature could be sacrificed in order to get a cleaner, more readable and easier to extend code structure. I'd love to get some feedback on this.... thoughts anybody? Then there's reading and parsing iTunesDB and its cousins. That code does not seem to handle variations in the format of the old iTunesDB file, let alone the notion that there may be a different file altogether to parse. cheers -henrik _______________________________________________ Bug-gnupod mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnupod
