Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

iTunes 10.6.3 breaks play #178

Closed
joeyw opened this Issue · 30 comments
@joeyw

All the iTunes commands are missing from Appscript after updating to iTunes 10.6.3. Airfoil and other apps still work with appscript.

wat

@slemiere

Yeah, just saw that as well. Had to downgrade to 10.6.1 to get it to work again.

@holman
Owner

Yikes.

@timkeller

Looks sandboxing related.

Calibre has run into the same issue: https://bugs.launchpad.net/calibre/+bug/1012243

Sadness.

@jayzes

@slemiere did you have a copy of the 10.6.1 installer locally, or were you able to find a download link somewhere? i've been having trouble finding an older copy to roll back to.

@joeyw

I will fix this.

@luisdalmolin

The only way to fix this is downgrading iTunes?

@holman
Owner

So far.

Apple is fun.

@ikennaokpala

Fun!! yeah the work around will do !!

@slant

For what it's worth, I have iTunes 10.6 (40) (whichever minor version that is) and while I am having a similar issue, I see a lot more commands using Appscript than joeyw sees. I get this error when clicking the link to add a song to the playlist.

My stacktrace:
https://raw.github.com/gist/a9f67a501fee92a159c2/e7e6a9dca16d710a64f609b6b6d58ac3ce0dadbf/gistfile1.txt

I would output the commands that I have through rb-appscript, but naturally, the connection that remote system is down. I will post them when I'm able to connect to that server. I just know that it was a lot longer and included play, pause, etc. I will also downgrade my version of iTunes and report back on how that works out.

@joeyw

Looks unrelated to this issue directly as I am running 10.6 (40).

@holman
Owner

Maybe it's time to yank iTunes out. Ugh.

@willglynn

Play already ships a Cocoa app for realtime notifications. [Edit: I'm thinking of #167, not mainline.] Would a Cocoa bridge to iTunes be similarly affected by sandboxing, or is this just a problem with rb-appscript and similar interfaces?

@willglynn

To answer my own question: iTunes control works beautifully from MacRuby via Scripting Bridge.

@ikennaokpala
@willglynn

Well, in macirb:

irb(main):001:0> framework 'ScriptingBridge'
irb(main):002:0> app = SBApplication.applicationWithBundleIdentifier('com.apple.itunes')
irb(main):003:0> library = app.sources.objectWithName('Library')
irb(main):004:0> library.playlists.objectWithName('iTunes DJ').playOnce(false)
irb(main):005:0> [ app.currentTrack.name, app.currentTrack.artist, app.currentTrack.album ]
=> ["Setting Sail, Coming Home (End Theme)", "Darren Korb", "Bastion Original Soundtrack"]

I've taken a crack at porting Play to use MacRuby + Scripting Bridge, and the iTunes-related models seem to work, but right now I'm hung up on some mundane problems getting the whole app to boot together with the web stack.

@fstoerkle

access to iTunes via MacRuby works for me, too
(OS X 10.7.4, iTunes 10.6.3)

@willglynn

So... MacRuby has some problems.

The json gem is broken. There's a workaround baked into MacRuby for require 'json', but bundler defeats this somehow. Shuffling around the versions of the gemset (sinatra_auth_github in particular) removes this dependency entirely.

The sass gem refuses to load (sass/sass#431). I can hack around this (sass/sass#432), but I'm not sure that it's working properly, and running the test suite explodes (MacRuby/MacRuby#113).

Once I get past that, the app takes forever, but it does eventually boot and start serving requests. Then it segfaults. I thought maybe it was something to do with EventMachine under MacRuby, so I swapped out thin for the MacRuby-native ControlTower app server. The official branch apparently hasn't been updated in ever, and requires an ancient, conflicting version of rack. A recent fork requires a newer, conflicting version of rack, but hey. Just to be extra annoying, it also doesn't have a control_tower.gemspec in the repo, defeating bundler's :git => "" syntax. And once you get it working... it crashes.

So, it seems to me that MacRuby is too immature to handle the Play application at this time. That said: iTunes 10.6.3 works beautifully from MacRuby. It's very performant, especially with Play using SBElementArray's valueForKey: (bulk fetching a key from all records with one context switch) and NSPredicate support (iTunes-side result filtering). It should also be possible to use MacRuby to hook into iTunes for immediate track change notifications.

For these reasons, I'm now tinkering with other ways to fit MacRuby into Play -- use a normal Ruby for the web app, and have it interface with MacRuby to talk to Objective-C. Play has a two-process model already; using a second Ruby to talk to iTunes wouldn't be that alien, and seems like a better alternative to forking out to osascript several times each request. ScriptingBridge is Apple's chosen way forward, and MacRuby -- warts and all -- seems to me like the least painful way to get there.

@holman
Owner

I think the plan is to merge #181 short-term, and then long-term rewrite Play.

@willglynn

Re-write Play how?

@holman
Owner

I want to drop iTunes at this point. I think it was a really rad idea and smart for a lot of reasons, but we want to layer more and more stuff on Play, and I'm starting to feel limited by being connected to iTunes.

Not to mention it sometimes releases patch versions that break the entire app.

@jparishy

Sounds like fun, I could probably throw something together this weekend if you wanted to test it out... Shouldn't be too difficult to throw together a music player with exposed AppleScript with a similar interface to what iTunes has. Unless you wanted to take this opportunity to change the architecture of Play so that it isn't made to work around iTunes' setup.

@holman
Owner

#181 will be our short-term fix, but after that I'm thinking an entire architecture overhaul. It's going to be a substantial thing.

I need time to sit down and detail some of the thoughts rattling around in my head- it's obviously a little bit more involved and would take some time. I don't have as much time to do it, so once I get the high points started I'd love to get some help on some of the specifics.

The main part of my thoughts now is spreading it out into separate components (and repositories): player, web, controller, library, streaming, airplay streaming, and so on, so it'll be much more focused per-app, much more testable, and, most importantly, much easier for you guys to jump in and help out without feeling like you're going to break the currently-fragile Play ecosystem. If we do go this route, splitting it into multiple projects would let me file a bunch of issues so I can get some direction for everyone who wants to help build this out.

The other main thrust of splitting all this out is actually to make it more easier to set up and more maintainable, even though at first it may sound like a ton of stuff going on. I have a lot of thoughts on how we can do that: one line installs, one line updates, no external dependencies on shitty GUIs, and so on. So don't worry if that's a worry. :)

@willglynn

Hooray, roadmap!

@jparishy

+1 for maintainability, testability, and ease of installation.

Might even be able to work out installing the server on another platforms so more people could use it. I'm looking for cool uses of my new Raspberry Pi :)

:thumbsup: Sounds like the right direction to me. Just let us know once you've knocked out those high points, I'd be glad to help flesh them out and I'm sure lots of people would too.

@holman
Owner

Might even be able to work out installing the server on another platforms so more people could use it

That's kind of the "hope to haves" coming out of this. I'm still fine saying that OS X is "the" platform for Play (just so we can focus on a really great, maintainable experience), but if we can do it on *nix without too much work, well, why not shoot for that too. Depends entirely on the type of components that make up the music side of things though.

@jparishy

Fo sho. Shouldn't be too difficult to design it in a way that would at least make it easy to do, even if it's not a priority. That's the kosher way to do it anyway, since you're looking to divvy up into smaller, isolated, and testable components. Not incredibly important right now, but fun stuff to think about.

@slant

I smell a delicious brew recipe. :)

@holman
Owner

That is of interest. Might be a good stopgap measure.

@joeyw joeyw referenced this issue from a commit
@joeyw joeyw Add manual iTunes appscript command definitions. Fixes #178.
Thanks to @jokull for pointing out this simple solution.
68bac2a
@cmeiklejohn cmeiklejohn referenced this issue from a commit in cmeiklejohn/play
@joeyw joeyw Add manual iTunes appscript command definitions. Fixes #178.
Thanks to @jokull for pointing out this simple solution.
80a6204
@spraints spraints referenced this issue
Closed

itunes 10.6.3+ #186

@joeyw joeyw closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.