Home

So this is the beginning of a project that I hope will be useful for office type networks, where a lot of people have shared itunes libraries. Right now all this does is parse your library (actually a test one at the moment, but you can easily change that by removing a comment), and print a few things about each track. I hope to store this info in a central database, and then make an interface to get various information out of it. The main thing I want to be able to do is search among various users for a song easily, but also some statistics of what is the most popular tune, etc… would be fun. I figure this main script will be something that runs here and there when you do stuff with the main interface maybe, to keep stuff up to date without being annoying.

== edit 7/9/2011 ==
I have a central server going where I am testing a lot of things out. I decided that it was too much of a limitation to require the central db to run inside a network, so I am going to revise things to allow a “home” that can live anywhere. For instance on someone’s web host, which should make this super easy to get going. In order to do this I ran into a few options…

1. Options for central db updating
2. 1) require central db to live on network, and thus we just connect to it like we’ve been doing.
3. 2) write api layer. So the client will be doing things, and
4. a) send a packet to the host after every song, exactly it is done now only with an api call, or….
5. b) send a batch of info to the api, and it will parse that out and deal with it.
6. 3) when a person updates their local db, and they have chosen to update the central one as well (if they have that choice),
7. then scp their whole local db to the central server. Then load that into a database and run pretty much the same code
8. then update the central db the same way we do now.

I don’t like the 3rd option really, it just seems janky. Also as I stated earlier the first is too restricitve. So I am going with the api layer (seems to be a theme these days). And I think I’ll just write some mass update calls, that will take a packet of json likely, and update the central db. I’ll for sure need to figure out what has/has not been updated after the xml parse, to keep this file as small as possible. So this is going to take a bit of work, but i think will be worth it once it is going.

To use this at the moment, just run…
python read_tunes.py user
== edit 4/17/2010 ==
Things are now at the point where this happens…
You run the command above….
If you don’t give a user it will try and use whatever you are logged onto your machine as.
If this user doesn’t exist, the needed directories and sqlite db will be created.
This user is inserted/validated against the central db
Your entire itunes library will be parsed, and the track title, artist, and album will be put in the local songs database.
The songs will be displayed as they are added.

== edit 7/04/2010 ==
I’m struggling with the flowchart for how this should work, and realizing how important it is to come up with this before hand
After going back and forth as to whether there should be a local db, etc…(right now the main reason I think it is important is for some type of quick local stats, and also to avoid doing a full update on the central db every time you run the “update”.
LOCAL USE
Run for the first time
--create local db
--handle user creation
--parse xml and populate local db
existing user
--parse xml and update local db
--remove deleted songs from local db

CENTRAL USE
--run through local db
--for each song, check to see if it exists in main, if not, add it
--add record for that song tied to that user
--check to see if this user has songs in main db that are no longer in local db, if so, remove from user/song join table
Check to see if anyone else has this song, if not, remove from main song table

So for this type usage, the web app will be a “read only” type thing. In order to update anything, you’ll need to do that from your local machine. This could clearly change, but for now I think this is the best step to get a fully functioning application going that can be built on.
== edit 8/8/2010 ==
Central db updates now.

Next:
Create web interface for central db
chris