Bug with i-Tunes integration

[Eric Walch]

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.

[Eric Walch]

The problem is in the apple script code. If I comment out the next function:

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]);
}

in the ooMusicController.m the Oolite hang is over. But I have no clue witch part of this code causes the hang.

[Kaks]

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:

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);
}

Edit: trying to display the exception type might be a bit of an overkill. If so, a simpler

Code: Select all

@catch (id exceptionType) {
      OOLog(@"iTunesIntegration.failed", @"could not connect to iTunes");
}

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:

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];

[JensAyton]

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...

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.

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.

[JensAyton]

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).

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.

[Eric Walch]

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).

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.

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)

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.

[Commander McLane]

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?

[goran]

I would try:
- Apple (CMD) + Tab to Finder
- Press Return or enter
- Press ESC

[JensAyton]

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.

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.

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.