Bug with i-Tunes integration
Moderators: winston, another_commander, Getafix
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
Bug with i-Tunes integration
Some weeks ago I noticed a bug with the mac build and i-tunes integration. The bug goes back to at least Oolite 1.71
When going to the game settings screen and selecting music things can crash when switching the value. It should switch between ON/OFF/i-Tunes. For that it checks if i-tunes is installed.
However, when i-Tunes is updated it displays a licence agreement first on the first launch. Oolite does not anticipates to that and hangs indefinitely, waiting for something that is not coming.
Just running i-Tunes first and agree to the terms fix this. Today I upgraded i-tunes again and went to Oolites music option without opening i-Tunes first. Oolite hangs again, waiting for something.
When going to the game settings screen and selecting music things can crash when switching the value. It should switch between ON/OFF/i-Tunes. For that it checks if i-tunes is installed.
However, when i-Tunes is updated it displays a licence agreement first on the first launch. Oolite does not anticipates to that and hangs indefinitely, waiting for something that is not coming.
Just running i-Tunes first and agree to the terms fix this. Today I upgraded i-tunes again and went to Oolites music option without opening i-Tunes first. Oolite hangs again, waiting for something.
UPS-Courier & DeepSpacePirates & others at the box and some older versions
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
The problem is in the apple script code. If I comment out the next function:
in the ooMusicController.m the Oolite hang is over. But I have no clue witch part of this code causes the hang.
Code: Select all
- (void) playiTunesPlaylist:(NSString *)playlistName
{
NSString *ootunesScriptString =
[NSString stringWithFormat:
@"tell application \"iTunes\"\n"
" if playlist \"%@\" exists then\n"
" set song repeat of playlist \"%@\" to all\nset shuffle of playlist \"%@\" to true\n"
" play some track of playlist \"%@\"\n"
" end if\n"
"end tell",
playlistName, playlistName, playlistName, playlistName];
NSAppleScript *ootunesScript = [[[NSAppleScript alloc] initWithSource:ootunesScriptString] autorelease];
NSDictionary *errDict = nil;
[ootunesScript executeAndReturnError:&errDict];
if (errDict)
OOLog(@"iTunesIntegration.failed", @"ootunes returned :%@", [errDict description]);
}
UPS-Courier & DeepSpacePirates & others at the box and some older versions
Apparently executeAndReturnError can be a bit of a headache.
It either crashes when it tries to allocate the error to errDict, or when it tries to access errDict inside the if clause...
We should be ok if we put a @try @catch construct around the whole executeAndReturnError bit, something like:
Edit: trying to display the exception type might be a bit of an overkill. If so, a simpler
might just be enough!
STOP PRESS & Edit2!: apparently making NSAppleScripts autorelease is not advised... even before trying @try @catch, which is a bit of a blunt approach, have a look to see if this stops the crashes:
It either crashes when it tries to allocate the error to errDict, or when it tries to access errDict inside the if clause...
We should be ok if we put a @try @catch construct around the whole executeAndReturnError bit, something like:
Code: Select all
@try {
[ootunesScript executeAndReturnError:&errDict];
if (errDict)
OOLog(@"iTunesIntegration.failed", @"ootunes returned: %@", [errDict description]);
}
@catch (id exceptionType) {
OOLog(@"iTunesIntegration.failed", @"encountered the following exception: %@", exceptionType);
}
Code: Select all
@catch (id exceptionType) {
OOLog(@"iTunesIntegration.failed", @"could not connect to iTunes");
}
STOP PRESS & Edit2!: apparently making NSAppleScripts autorelease is not advised... even before trying @try @catch, which is a bit of a blunt approach, have a look to see if this stops the crashes:
Code: Select all
NSAppleScript *ootunesScript = [[NSAppleScript alloc] initWithSource:ootunesScriptString];
NSDictionary *errDict = nil;
[ootunesScript executeAndReturnError:&errDict];
if (errDict)
OOLog(@"iTunesIntegration.failed", @"ootunes returned :%@", [errDict description]);
[ootunesScript release];
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
The problem Eric is talking about isn’t a crash, it’s the synchronous nature of AppleScript. iTunes doesn’t respond to incoming events when it’s showing a modal dialog.Kaks wrote:Apparently executeAndReturnError can be a bit of a headache.
It either crashes when it tries to allocate the error to errDict, or when it tries to access errDict inside the if clause...
Ideally, we’d be able to make the whole set of commands send asynchronously, but we can’t (short of running the script in a separate process). Another workaround is to use a timeout in the AppleScript code. I’m doing that now.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Actually, it turns out that we can, but it’s not useful in this case because we need to get a reference to the playlist back from iTunes. Anyway, the timeout version is in r3097.Ahruman wrote:Ideally, we’d be able to make the whole set of commands send asynchronously, but we can’t (short of running the script in a separate process).
E-mail: [email protected]
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
Thanks, fix confirmed. I intentionally did not agree to the new i-Tunes licence after updating yesterday to check this bug. After applying your fix, Oolite no longer hangs on switching. (Only the one second you defined in the timeout)Ahruman wrote:Actually, it turns out that we can, but it’s not useful in this case because we need to get a reference to the playlist back from iTunes. Anyway, the timeout version is in r3097.Ahruman wrote:Ideally, we’d be able to make the whole set of commands send asynchronously, but we can’t (short of running the script in a separate process).
But does this mean that there are only very few Mac players that have i-Tunes integration switched on? Because I noticed the bug while switching the music option, but when it was already set to i-Tunes integration, Oolite would hang during startup. And this happens already quite long. I just checked 1.70 and older does start, but since 1.71 oolite hangs during startup when i-Tunes was not started after an update.
UPS-Courier & DeepSpacePirates & others at the box and some older versions
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
I know this is not the right forum, but—what the heck, were we ever shy to derail a thread here —this reminds me of a very annoying general problem with OS X. Or perhaps I am just too stupid?
Every once in a while I am in full-screen mode (for instance watching a slide show in iPhoto), when in the background, invisible and unbeknownst to me, an alert box pops up (for instance telling me that my battery runs low). At this moment the MacBook freezes, sort of. It doesn't actually freeze, but I am required to click the "OK" in the alert box before I can do anything else. But I am not aware of the alert box, because it is not visible. And whatever I am actually doing (slide show) doesn't continue, because of the alert box. Specifically, I cannot end the slide show because of the invisible alert box, which I would need to make the alert box visible and clickable in the first place.
The only thing I know to do is to force a complete shutdown by pressing the power button for a couple of seconds. But this of course means that everything I have worked on at the time is lost. Really annoying. So I am asking myself: is it me? Am I doing something wrong? What do other people do in this situation?
Every once in a while I am in full-screen mode (for instance watching a slide show in iPhoto), when in the background, invisible and unbeknownst to me, an alert box pops up (for instance telling me that my battery runs low). At this moment the MacBook freezes, sort of. It doesn't actually freeze, but I am required to click the "OK" in the alert box before I can do anything else. But I am not aware of the alert box, because it is not visible. And whatever I am actually doing (slide show) doesn't continue, because of the alert box. Specifically, I cannot end the slide show because of the invisible alert box, which I would need to make the alert box visible and clickable in the first place.
The only thing I know to do is to force a complete shutdown by pressing the power button for a couple of seconds. But this of course means that everything I have worked on at the time is lost. Really annoying. So I am asking myself: is it me? Am I doing something wrong? What do other people do in this situation?
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
That shouldn’t happen in a properly implemented full-screen app (like Oolite). If it does, it’s a system bug (the system is supposed to ensure that other applications can’t steal focus when the screen is “captured”). Unfortunately, many full-screen apps are not properly implemented.Commander McLane wrote:Every once in a while I am in full-screen mode (for instance watching a slide show in iPhoto), when in the background, invisible and unbeknownst to me, an alert box pops up (for instance telling me that my battery runs low). At this moment the MacBook freezes, sort of. It doesn't actually freeze, but I am required to click the "OK" in the alert box before I can do anything else. But I am not aware of the alert box, because it is not visible. And whatever I am actually doing (slide show) doesn't continue, because of the alert box. Specifically, I cannot end the slide show because of the invisible alert box, which I would need to make the alert box visible and clickable in the first place.
If goran’s suggestions don’t work, try holding down option, command and escape for several seconds.
A similar-yet-technically-different problem can occur when debugging a “proper” full-screen app. My solution then is to log in through ssh and kill Oolite and, if necessary, Xcode. This requires an additional computer (or smartphone) and a known network address for the “frozen” Mac, though.
E-mail: [email protected]