Hi happy Perl People,
http://slowass.net/user/scott/make_itunesdb.pl.txt is a smallish Perl program to create an iTunesDB from the mp3 files already on an iPod.
The idea is that you can just cp -R, rsync, drag and drop, or otherwise get the mp3s there however you damn well please.
If you're not away, Apple's firmware won't play mp3s not in the iTunesDB.
There are about 20 programs that give you kio slave interfaces, GUIs, shell tools, etc to copy files to your iPod, but as far as I've seen, nothing to support plain old ''cp''.
Well, here it is.
Ideally this would run on the iPod itself, and I suppose it could be rewritten in C (still no iPod Perl, but there is an iPod Python), so that you can still rebuild your iTunesDB when you're away from home.
This was based on another program whose name I forgot but it's author is credited in the copyright in the file (GPL).
It writes an older version of the iTunesDB file, but my 2nd gen iPod Nano accepts it.
Most of the code was pruned away, as you'd expect, and bugs were fixed (more like incompletenesses) in the existing code.
The --root specifies the root of the iPod device (eg, where you have it mounted).
If you don't have an iPod_Control, iPod_Control/Music, and iPod_Control/iTunes, you'll want to make them. I think there's still an option to do it, but I'll probably remove that, because, gosh, Unix already comes with a command to make directories, and I'm still holding a grudge against all the twits who tried to re-invent cp.
It will almost certainly complain that your
filenames are too long.
This isn't a limitation of this little program
but instead of Apple's firmware -- paths
longer than 36 chars get truncated, resulting in
the iPod being unable to find the file.
Considering the file format, this is completely unnecessary as this is a length-counted field.
To make matters even dumber, the path must start
with ':iPod_Control:Music:' or the damn thing
won't play the track either!
So there are very few (I'm too disguested to even count) characters left.
You'll want to shorten directory names yourself
probably.
Anyway, there's a --mangle option to automatically remove characters from directory and filenames until the path is short enough, but I promise you, it'll leave you with garbage.
This is not an rsync-friend situation.
Maybe I can do something with generating the garbage filenames (00/01.mp3) that Apple likes and having those be a symlink to the actual track or vice versa.
Except FAT32 doesn't exactly do symlinks.
Argh.
Too many mp3s in one directory will bog the iPod down, too, by the way.
Also of note, iPod Linux is frickin' awesome, but it's MPD creates its database from the iTunesDB, so you need a valid iTunesDB -- you can't use the file browser to find an mp3 and then just play it, at least not yet.
On the other hand, it would be a lot easier to generate the plain-text file MPD wants than it would be to create the iTunesDB file, which is binary, complex, redundant, overly extended, under documented, and fickle.
It's extremely neat to be able to put a track on and then go play Vortex, the Tempest 2k clone.
There's still too much skipping, even in the menu (actually, especially in the menu).
PodZilla needs to be optimized a bit before it can coexist with MPD.
Can't create calendar entries yet, but you can edit text files and paint pictures, and there's a terminal!
Input is done several ones, the most basic of which is using the thumbwheel to pick the character from a big list.
And the GUI is themeable with loads of fonts and decorations from a dozen different computer systems.
You cannot get an iPod and not install Linux.
It's just too good.
Most of my code gets posted in conjunction with
phoenix.pm.org, but this one isn't on-topic enough.
I tried to find something like this, failed, and had to make my own, so I wanted to put it back out there.
I'm interested in feedback on ways to handle the iPod firmware's limitations but realize that this is basically a quick hack for me to scratch an itch.
Cheers,
-scott
