Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/frontierdesign/frontierdesign.com/forums/include/parser.php on line 684

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/frontierdesign/frontierdesign.com/forums/include/parser.php on line 738

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/frontierdesign/frontierdesign.com/forums/include/parser.php on line 738

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/frontierdesign/frontierdesign.com/forums/include/parser.php on line 738

Topic: iTunes Control in OS X Leopard

drix wrote:

Leopard and Tranzport in iTunes mode has to serious bugs:

1. A process called 'tranzport menu' uses 30-50 % of CPU.

2. When quitting iTunes, it constantly gets relaunched - until you unplug receiver or grabs tranzport manager and select anything other than iTunes control. (This bug was also valid for 10.4 Tiger)

Being quite frustrated and annoyed about this, I've been unsuccessfully checking every month for any updates since the 'latest' package of april 2007 (1.4.2).

I'm aware that AlphaTrack is the newest and most exiting product, but TranzPort's still very relevant and essential for all of us without iPhone-remotes.

I really wonder if these issues ever going to get addressed, since we're now more than 10 months into Leopard and there hasn't been any notice of known issues, workarounds or updates.

Best, Henrik

Simplemind wrote:

Greetings Henrik,

We have looked into this and haven't come up with a conclusive fix yet as it seems to be related to changes in iTunes and/or Applescript in the new OS. On the mac we are limited to using Applescript to communicate with and control iTunes. Oddly the exact same script calls end up using more CPU on Leopard. We've gone through them one by one to see if there's a single "smoking gun" that might be causing the load but that wasn't the case.

If you want to reduce the load I would suggest hitting a Rec/Mute/Solo button. This puts the interface into a different mode, thus greatly reducing the amount of polling of iTunes and the overall load. Hit Undo to return to "normal" mode. Of course this means you have to hit undo whenever you want to see the current track or other information about it, but it is a means to reduce the load.

This might also help in shutting down the app, but I've gotten mixed results with that. It's related to the same overall slowdown of applescript/itunes interaction: we check to make sure iTunes is running before asking it for information, but if you happen to quit between that check and the applescript query then the query causes iTunes to fire up again.

Hope that helps.

-Jerry

drix wrote:

Greetings Jerry,

Many thanks for the swift and elaborate reply!

I will try using the artist/album/song filter mode as a workaround.

And thank you for acknowledging these issues, it's quite reassuring knowing they're being investigated.

Ciao from Henrik