Re: [Bug-gnupod] iPod Shuffle 3rd Gen: Status?

[H. Langos]

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