Open Radar

 
With iTunes 10.6.3, sending an ascr/gdte Apple Event returns the generic ("Standard Suite") scripting terminology instead of the iTunes scripting terminology. This breaks (among other things) remote scripting.

Steps to Reproduce:

On machine 192.168.0.1, enable remote scripting, start iTunes, and select the first track.

On another machine on the LAN, run the two following one-liner scripts (either via AppleScript Editor or osascript):

tell application "iTunes" of machine "eppc://192.168.0.1" to selection

tell application "iTunes" of machine "eppc://192.168.0.1" to first track

Expected Results:

Both commands should return something like {file track id 127126 of user playlist id 126691 of source id 73 of application "iTunes" of machine "eppc://192.168.0.1"}

Actual Results:

The first command returns something like {«class cFlT» id 127126 of «class cUsP» id 126691 of «class cSrc» id 73 of application "iTunes" of machine "eppc://192.168.0.1"}

The second command fails to run, with the error "Expected class name but found identifier."

Regression:

This worked as expected with iTunes 10.6.1, and every other version back into the mists of time. It doesn't matter which OS version you're running on either machine; all that matters is the iTunes version.

Notes:

I do not know of any way to work around this in AppleScript.

Calling OSAGetAppTerminology instead of sending ascr/gdte seems to work. However, that method is deprecated, doesn't work in 64-bit apps, and doesn't work remotely. And besides, it's not what AppleScript does for remote scripting, so even if this were an option, you'd have to rewrite all your scripts in C to take advantage of it.

Another workaround is to run the sdef tool on the remote machine, copy the resulting sdef to the scripting machine, and use it as static glue with the appscript library. (The dynamic-glue features of appscript, and the ASTranslate tool, are broken by ITunes 10.6.3, even locally, for exactly the same reasons as remote AppleScript, but with static glue everything still works.) That at least allows you to rewrite your scripts in Python, Ruby, or ObjC instead of C. But it's still pretty drastic. Plus, appscript is a third-party library that's no longer maintained.