• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
SOLVED: Cocoa, iTunes, AppleScript - performance issue BUT a Question arises
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SOLVED: Cocoa, iTunes, AppleScript - performance issue BUT a Question arises


  • Subject: SOLVED: Cocoa, iTunes, AppleScript - performance issue BUT a Question arises
  • From: Steve Cronin <email@hidden>
  • Date: Thu, 13 Sep 2007 11:39:26 -0500

Folks;

[Wiping his face somewhat disgustedly]   Hrmmph,  well uh let's see.

I was running the script cited below in response to a drag event from iTunes and I had not returned from -[performDrag ..].
So iTunes was thrashing on its first task - disposing of the drag request- while I was held out twiddling waiting to get some priority on my script.


Once restructred so my script runs after returning out of - [performDrag ..] all is well..

I do have a question here tho:

The normal response to a drag out of iTunes is to write an .mp3 file.
I don't want the files. I can get all I need from the property list on promised files.
I'm using the drag to transmit meta-data not files!!


So I am grabbing what I need and then returning NO from - [performDrag ..] to avoid the unnecessary resource drain of all the file handling.
This may seem disconcerting to the user and it feels like maybe I should clarify with a dialog but I don't want the interruption.


Is there a better resolution?

Steve

On Sep 13, 2007, at 3:11 AM, Steve Cronin wrote:

Folks;

I have a set of applescripts compiled into a .scpt resource which I deploy as part of an application.
I have several utility type scripts which I call using something like this:


NSDictionary *errorDict;
NSAppleEventDescriptor *thisResult;
NSAppleScript *myAppleScriptUtilities = [[NSAppleScript alloc] initWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"ASUtilities" ofType:@"scpt" inDirectory:@"Scripts"]] error:nil];
NSString *str = [myOSXUtilities launchApplication:@"com.apple.iTunes"];
if ([str isEqualToString:@"True"]) {
thisResult = [myAppleScriptUtilities executeAppleEvent:[self callSub:@"applyGoodnessToTunes" params:
[NSAppleEventDescriptor descriptorWithString:theGoodness], [NSAppleEventDescriptor descriptorWithString:trackID], nil] error:&errorDict];


I have been pretty happy with this setup - I have several different scripts (Finder & Mail) working.
Now I have begun to tinker with iTunes.


I have logging enabled in the applescripts so that I can debug and then later so the customer can help me debug.

I have a simple script which writes some metadata to selected tracks:
set startTime to (current date)
my writeToLog("Tunes", "-- NEW SESSION --")
...
set pidC to length of myPIDList
repeat with j from 1 to pidC
tell application "iTunes"
my writeToLog("Tunes", "talking to iTunes - track count: " & pidC as text)
set oldfi to fixed indexing
set fixed indexing to true
my writeToLog("Tunes", "iTunes fixed indexing set ")
...
set fixed indexing to oldfi
end tell
end repeat
set deltaTime to (current date) - startTime
my writeToLog("TagTunes", "ready to return - total time: " & (deltaTime as text) & " secs")



Now, this snippet rocks when testing in Script Editor.

BUT when I run my Cocoa app and call out as above here is actual data from the log:
Thursday, September 13, 2007 2:54:47 AM -- NEW SESSION --
Thursday, September 13, 2007 2:54:47 AM talking to iTunes - track count: 5
Thursday, September 13, 2007 2:54:47 AM iTunes fixed indexing set
Thursday, September 13, 2007 2:54:47 AM top of loop -- track pid: 93DF7AD675F07E3C
Thursday, September 13, 2007 2:55:11 AM track pid access completed: 93DF7AD675F07E3C
Thursday, September 13, 2007 2:55:11 AM ready to apply changes : Everything
Thursday, September 13, 2007 2:55:11 AM talking to iTunes - track count: 5
Thursday, September 13, 2007 2:55:11 AM iTunes fixed indexing set
Thursday, September 13, 2007 2:55:11 AM top of loop -- track pid: 93DF7AD675F07E40
Thursday, September 13, 2007 2:55:11 AM track pid access completed: 93DF7AD675F07E40
Thursday, September 13, 2007 2:55:11 AM ready to apply changes : Eight Easy Steps
Thursday, September 13, 2007 2:55:11 AM talking to iTunes - track count: 5
....


As you can see there is a nearly 25 SECOND delay as the session gets initiated.
I have seen the delay stated before the 'fixed index'...
but it always happens AND
it always happens only once and
it only happens at the start of the first time thru the loop.
It seems to me to be related to the first command given to the iTunes tell block....


I have tried several different approaches but nothing has changed the 25 SECONDS!!
(BTW: this is a 1G MacBook running 10.4.10 and XCode 2.4.1)


I am not sure what to do next.

Does anyone out there have any ideas on what could be causing this?

I have not seen anything like this for the other AppleScripts I have developed.

Thanks for any help!
Steve



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Parallel instances of Cocoa apps?
      • From: Jay Reynolds Freeman <email@hidden>
References: 
 >Cocoa, iTunes, AppleScript - performance issue (From: Steve Cronin <email@hidden>)

  • Prev by Date: Re: Incremental Development?
  • Next by Date: Re: resetting ivars safely
  • Previous by thread: Re: Cocoa, iTunes, AppleScript - performance issue
  • Next by thread: Parallel instances of Cocoa apps?
  • Index(es):
    • Date
    • Thread