[Pythonmac-SIG] appscript: selecting many songs in iTunes
hengist.podd at virgin.net
Wed Jan 18 16:03:20 CET 2006
Niko Matsakis wrote:
>>Well, I'll benchmark the two approaches against my full library and
>>report back on the results :). The question is whether having more
>>AppleEvents will be slower than selecting way too much data.
>Neither is stupendously fast; the bottleneck is definitely issuing the individual delete commands for each track. Both took around 30 minutes to execute. It seems to take around one second for a delete command to take effect, judged solely on watching the total track count decrease one by one.
Still sounds very slow. What OS & iTunes versions; how big's the playlist and what % is duplicates? I mocked up a 550-item playlist containing 500 duplicates and my script took 50 secs to get through that (iTunes 6.0.1; OS 10.4.3); 10 secs if I close the playlist window first so iTunes doesn't have to update that each time.
>Actually, I have one final question: is it possible for handles to "time out?"
What you mean by 'handles'? If you mean application object references, remember those are just queries, so they're only as durable as they are unique. A by-id specifier should always identify the same object for as long as that object exists; a by-index specifier will identify whatever object happens to be at the specified position at the time, which may well be different objects at different times if you're moving them around and stuff.
Individual Apple events can time out if the application takes too long to handle them; e.g. try getting the 'entire contents' a large chunk of your filesystem in Finder, and, assuming Finder doesn't just collapse in a heap from the strain of it, chances are the Finder won't have completed the operation and sent its reply before the default 60 second timeout expires, in which case AEM sends a timeout error back to your script. (You can adjust the timeout delay if you need to; see ch.10 of the appscript manual.)
More information about the Pythonmac-SIG