iTunes Remote for OperaDS

Well, us, really.

Since I never felt comfortable telling people to run Apache as their user (which is giving a web server read-write privileges to everything you have those privileges for!) I've been searching for another way to poll iTunes for info and send commands to it via a web interface, because the www user (Apache and PHP) can't do it directly through AppleScript.

In searching for a solution, I found brian d foy's Matthew Russell's excellent article (MacDevCenter.com -- Build an iTunes Remote Control) on using a shell daemon to read a temp file and pass what it finds to osascript. I tried out his scripts, but (under 10.4, at least) the daemon script's process name is bash, making the companion script used to kill it worthless. So I says to myself, "Self, looks like you're gonna be learning some Perl."

Wrong! I'm a coward, I admit it. But I have a very good reason to make this project easier: Folder Actions. A daemon that already runs and performs any AppleScript you can write based on the conditions you give it.

What now? I'll tell you what now.

• Scrap the PHP "exec(osascript)" from the current package.
  
• Write "tempnam()" routines for the control input that write commands to a file. The file name will include the user name (taken from iTunesDSr "pwd") so the next step can use it properly.
  
• Write a Folder Actions script that runs when a file pops up in the tmp directory. If it's an appropriately named file, it will read it and pass the commands to iTunes.
  
• If possible, use this same Folder Action to write a file containing iTunes current info, another file for all playlist names, perhaps another with current playlist track names. If not, write a companion, stay-open AppleScript app that can.
  

The hard part, perhaps even a sticking point, will be timing these scripts so they fire when needed, but not after the next step in another script has passed. In first tests, the PHP tempnam() routine must sleep() for 2 seconds to give Folder Actions a chance to see the file.

Given that, this method will be more sluggish than what I wanted it to be. But if it keeps some a-hole, or some worm from reading your user files (or worse), it's well worth the inconvenience.




Thanks to brian d foy for correcting my mistake on citing his Perl article (MacDevCenter.com -- Controlling iTunes with Perl) and for pointing out the Perl extension Mac::AppleScript (Mac::AppleScript - Perl extension to execute applescript commands on OS X - search.cpan.org). If this project interests you I suggest you check it out.

Fast User Switching - 1
AppleScript - 0


The instance of iTunes that receives Apple Events is the one running under the current user. I've noticed this behavior with Remote Apple Events apps that want to control iTunes. What this means is that if you're blasting iTunes and another user switches to their account, your iTunes stops responding to AppleScript commands.

Now, hold on a minute! iTunes does respond to AppleScript from another app running under the same user, active login be damned. For instance, I have an AppleScript Studio app I made to update a "last song played" PHP script. The result of which can be seen on my homepage (StrawHousePig - Home) and in the form of an image I use for profile or sig pics at various forums that allow it.



The AS Studio app polls iTunes and sends current track info to the PHP script. I always meant to finish and release it, but once I got it working for us I said, "screw it, good enough". The important thing here is that it updates without my user being active.

So while it may be kewl to hi-jack your wife's or other relatives iTunes, it's only funny till they hear you laughing about it. Actually controlling your iTunes would be much better. Though the real value of doing so is made moot unless you're streaming iTunes through an AirPort Express or other means as that's the only way to hear your iTunes while your user isn't the active one.

I'll have to look into running an AS app that can pass ARGVs from osascript to iTunes as commands. But, osascript may break that.


The point of all this is that with this technique it should be possible to run Apache as www instead of a "real" user, making it much more secure to use.

Thanks to Mark Hunte @ MacScripter BBS | Applescript Forums for the much faster artwork wrangling routines.

It now goes by album instead of track by track. I know some iTunes users out there only put artwork into one file per album in an attempt to reclaim disk space. Hopefully it's in the first track.



This software is currently not recommended for use!

A more secure (and multi user friendly) version is in the works.

And by "in the works" I mean my brain has formed an idea that doesn't require running Apache as a user other than www. The exec(osascript "foo") portions need to be scrapped and a stay open AppleScript app still needs to be written.

Stay tuned.