ITunes Remote: Just does nothing?

The code underneath this feature has been re-worked for the next major patch after 1.12.x series, and no longer has these delay / osascript issues.

Basically it was originally coded using AppleEvent communication techniques and put out for testing in the 1.12 PTR. Howver there were some really problematic failure modes with that approach, the big one was if iTunes was hidden and ever presented a dialog in response to a request (example: FairPlay authorization dialog for a purchased track) WoW would get stuck waiting for an answer, and the user would not be able to recover if WoW was full screen mode.

Rather than pull the feature entirely for 1.12.0, a Plan-B version was shipped using 'osascript' to route commands to iTunes; not our first choice but it did solve the blocking/deadlock issue. But as you can see that's a bit clunky and not snappy.

The code in the next major patch has the best of both worlds - non blocking behavior and using a native AppleEvent approach to communicate directly with iTunes without the overhead of using osascript. It is noticeably better.

This feature has been largely re-written for the next major patch, and no longer depends on having the "osascript" tool installed. It's also a much smoother implementation without the big hit to framerate when invoked, and the "HUD" track info display is back again as well. However, if you are on a system with the minimum RAM, you may see some lag when trying to use this feature due to virtual memory swapping.

I've adopted the habit of referring to the next major patch without mentioning a version number, because plans have shifted a couple times internally with regards to naming and I wouldn't want to post something that would be seen as inaccurate or dated.