Scripting Bridge & iTunes?

Question

Hi, has anyone gotten very far into using Scripting Bridge on Leopard with Python and iTunes? I tried, but got stuck pretty fast. I'm trying to iterate over tracks and (among other things) find out what their file names are.
from ScriptingBridge import *
itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
lib = itunes.sources()[0].playlists()[0]
tracks = lib.tracks()
print tracks[0].location
This works up until the last line, but then complains "AttributeError: 'ITunesTrack' object has no attribute 'location'". So I thought I would try to ask for a list of "file tracks" instead of "tracks", because that's how appscript seems to work, but no luck.
from ScriptingBridge import *
itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
lib = itunes.sources()[0].playlists()[0]
tracks = lib.file_tracks()
print tracks[0].location
produces "AttributeError: 'ITunesPlaylist' object has no attribute 'file_tracks'". And then, although I really want to embrace Scripting Bridge, I thought I'd try a last resort and go back to using appscript (that's what I used on Tiger). But that doesn't seem to work on Leopard... while retrieving the list of tracks, it works for a while and then says
Traceback (most recent call last):
File "/Library/Python/2.5/site-packages/appscript-0.17.2-py2.5-macosx-10.5-i386.egg/apps
cript/reference.py", line 372, in _call_
if e.number in [-600, -609] and self.AS_appdata.path: # event was sent to a local app
for which we no longer have a valid address (i.e. the application has quit since this aem.
Application object was made).
AttributeError: AppData instance has no attribute 'path'
even though iTunes hasn't quit. Any suggestions? I know I could read & write XML, but I want this to work while iTunes.app is running. This seems like it ought to be a really basic task, but I'm out of ideas. Thanks in advance.
Message was edited by: dormouse310

Answer 1

The problem here is that Scripting Bridge is just a bit too arrogant and nit-picky for its own (or its users') good.
i.e. Unlike appscript, which carefully mimics the way that AppleScript works in order to ensure maximum compatibility with existing applications - all of which have for the last 14 years been designed and tested against AppleScript - Scripting Bridge tries to impose its own particular ideas of how application scripting should operate. The result is that applications which work fine with AppleScript but don't precisely behave in the way that Scripting Bridge thinks they should behave can end up being partially or even completely inaccessible to Scripting Bridge users (at least not without resorting to klunky low-level workarounds).
(Incidentally, I did caution Apple a year ago about the compatibility problems that the Scripting Bridge-style approach would cause - I made some of the same mistakes myself in early versions of appscript - but unfortunately they went ahead and did it anyway.)
In this case, it's Scripting Bridge's insistence on enforcing the object model structure defined in iTunes' dictionary that's causing the problem, since iTunes' dictionary is rather inconsistent in declaring the types of elements each class supports. For example, if you look up the 'playlist' class's definition, you'll see that it forgets to list 'file track' as an element. This doesn't bother AppleScript (or appscript), but it trips up the rather less tolerant Scripting Bridge, as you can see here:
from ScriptingBridge import *
itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
lib = itunes.sources()[0].playlists()[0]
filetracks = lib.fileTracks() # this line raises an AttributeError: 'ITunesPlaylist' object has no attribute 'fileTracks'
print filetracks[0].location()
Not that this excuses the iTunes developers for their sloppy documentation, mind (and you should definitely file a bug report on it), but it isn't much consolation to users who just want to do things that they know worked fine in AppleScript or appscript.
Anyway, it is possible to work around this particular limitation in Scripting Bridge by resorting to raw AE codes; in this case:
import struct
from ScriptingBridge import *
itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
lib = itunes.sources()[0].playlists()[0]
filetracks = lib.elementArrayWithCode_(struct.unpack('>L', 'cFlT')[0]) # filetracks = lib.fileTracks()
print filetracks[0].location()
To obtain the raw codes, use ASDictionary's plain text export option, Smile's 'copy translate' feature, Script Debugger's advanced dictionary viewer, or save the dictionary as an sdef file in Script Editor. And don't forget to take account of endianness issues when converting four-char-code strings to ints as shown above.
As for the error you're getting with appscript:
Appscript identifies local applications by their process numbers, so if you quit and relaunch an application after you've created an 'app' object for it and then use that app object to send the application another command, appscript will deliberately raise an error (-609) to tell you the process number used by that app object is no longer valid. (Note: you should actually get a CommandError, not AttributeError, here - the error message you're actually seeing is caused by a bug in 0.17.2's error handling/reporting code that's since been fixed - but the general explanation still holds.)
In your case, however, it sounds as if iTunes is running throughout, so that isn't what's causing appscript to error. I suspect the actual cause is a timeout error; unfortunately this gets wrongly reported in appscript as error -609 instead of -1712 (timeout error) as it should be. Obviously, getting the wrong error message when an error occurs is rather confusing for users, and fixing this problem is on my TODO list for the next release, although I've yet to figure out why the Apple Event Manager should be giving appscript the wrong error number in the first place. In the meantime, you should be able to confirm that it's a timeout error by running the equivalent command in AppleScript within a 60 second timeout block (which is, IIRC, the default timeout used by appscript 0.17.2).
As to why it can take so long to get file tracks in iTunes - I'm not an iTunes guru, but you could try asking on the AppleScript-users mailing list to see if anyone there has any suggestions. As for avoiding timeout errors in the first place, you can increase the timeout delay for your appscript command via its 'timeout' argument (this is equivalent to AS's 'with timeout' block, except that it only affects the command it's used in) - see ch.11 of the appscript manual for details.
HTH
has
(p.s. If you've any questions or problems with Python appscript, best place to post them is the PythonMac-SIG mailing list at python.org, or mail me directly if you prefer.)