Indrio Development Begins: iTunes, COM & Python

Indrio is the name or a road not too far form here. Indrio is also the code name for a little project I’m working on to help me learn Python. It involves talking to iTunes, over COM. This is easier than it sounds. The iTunes SDK documentation is well written, well organized and easy to understand. It’s an easy API to work with, thats the good news.

The bad news is that some of the cool stuff that iTunes is doing in the UI is not available through the COM interface. Of particular interest to me was the Party Shuffle playlist. You can add tracks to it but only at the end i.e. No “Play Next in Party Shuffle” via COM. You can’t determine how many previously played tracks are showing (unless your actually playing that playlist and work it out from the currently playing track). You can’t set the playlist that feeds into the party shuffle or any of the other parameters. These things are not blockers for what I wanted to do but they would have made things much nicer for users.

Then there is fun with ID’s. The docs say that all objects in iTunes support four script friendly functions to return the Source, Playlist, Track & Database ID’s respectively. If you have a problem accessing these functions its because the Source, Playlist and Track functions are declared to start with common letters; sourceID(), playlistID(), trackID(). The database ID function is capitalized as per the docs: TrackDatabaseID(). Also of interest, Python can handle the multiple return values of GetITObjectIDs() by turning them into an array. Score one for Python! Score another one for the Python COM browser which helped me track down the capitalization bug.

iTunes.GetITObjectByID() doesn’t work if all you have is the Database ID, which makes knowing that basically useless. To make GetITObjectID() work you need to know all 4 parameters. That isn’t exactly congruent with the docs. Supplying 0 to any of the parameters throws some sort of error.

The final twist is with Python. It supplies base types when a function returns a derived type over COM. So you have to cast the return type to the type you expected. This had me stumped for a while until I saw this Simon Brunning’s code. win32com.client.CastTo() is the magic bullet that fixes this. I wish there was some good docs for the Python COM interface.

Stay tunes for the next installment where I reveal even less about what Indrio might be or do or why you should care…


Tags:

 
 
 

2 Responses to “Indrio Development Begins: iTunes, COM & Python”

  1. Gravatar of David Worton David Worton
    14. August 2008 at 02:35

    Working on my own iTunes utility in C# and COM and I too have observed this problem with GetITObjectIDs. The COM documentation is good but it all seems a bit convoluted to have to supply four parameters to get an object back. Shouldn’t the whole the point of a unique database ID be so that you can retrieve an object directly from the database with ONE parameter? Ah well, I expect I’ll find a work around…

  2. Gravatar of Gareth Farrington Gareth Farrington
    20. August 2008 at 08:35

    Yea, I pretty much abandoned this project. iTunes doesn’t allow you enough access to do the things I wanted to do. The API is a little janky and hasn’t changed since they released the original iTunes on Windows.

    I think the tools that work really well with iTunes end up just parsing the XML library file themselves.