Bugs
Multiple Library Confusion
I've just posted a brief article explaining how your system can get confused when using iTunes' multiple library feature:
Some of my AppleScripts for iTunes use a routine which reads the iApps.plist in order to obtain the location of the current iTunes library's XML file in order to get information from it. I occasionally get reports that these scripts don't seem to be working correctly; that the information seems to be wrong or doesn't correlate with track tags in iTunes. When the Correspondent and I investigate this phenomenon, very often it is because the iApps.plist contains the wrong location for the current iTunes library....read more here.
It's Official
I got a follow-up email to my bug report to Apple regarding the iTunes 7.7.1 "whose clause" to-do: "Engineering is no longer able to reproduce the issue with iTunes 8." The iTunes guys put things back the way they were, more or less. An implied list (using "every" as the specifier or a range) returns a list or empty list, an implied single entity specifier ("first", "last", "some", and so on) returns a bare value.
Genius 4010 Error
This Apple forums discussion post describes an error that many iTunes 8 users are getting:
"iTunes 8.0 gathers data about my music library well enough and sends it to Apple too; but then 10-15 seconds into 'processing' by Apple, iTunes stops and reports that 'Genius results can't be updated right now. An unknown error occurred (4010)'. I thought it might be overloaded servers and tried several more times in the hope of squeezing my request in between those of everyone else; but that didn't work; plus if it were a server issue I'd expect to see postings here from others with the same problems, and I'm not."
Several posters have tried removing dead tracks--tracks whose files cannot be located as designated with the encircled exclamation point--from the library using the script Super Remove Dead Tracks and trying again, and although this didn't work for everybody, several posters did get things working correctly afterwards.
iTunes 8
Apple released iTunes 8 today at the "Let's Rock" event.
Happily, the "whose clause" bug from v7.7.1 has been fixed: a filter using an implied plural ("every" or a range) will return a list and one that implies singularity ("first", "last", "some") returns a bare item. As it should be.
More as it develops.
Some iPod-Related Updates
Correspondents had been recently reporting a common problem with several scripts that copy files to iPod where files would not be completely copied before their originals were removed; thus only a few tracks would get copied. I've fixed the issue (and I do not know for sure if it was caused by an iTunes problem or a Doug problem) and the scripts have been updated and posted.
Updates Coming
I am working on updating several scripts and apps to accommodate the iTunes 7.7.1 issue and I'll be posting them when I can. Notably, Tracks Without Artwork to Playlist and Make Video Tags will be among the first to get fixed.
AppleScript Bug or Feature in iTunes 7.7.1
I think I have found a rather unusual AppleScript bug (or perhaps feature; one never knows) in iTunes 7.7.1. It affects several scripts that may need to reference a track using a persistent ID. When attempting to reference a single track with a whose clause, the track reference is returned coerced as a list. This requires that an additional step be taken to extricate the single item (the track reference) from the list. I have filed a bug report. It is reproducible with this script:
tell application "iTunes" set t to item 1 of selection set p to (get persistent ID of t) log ("p: " & p) set the_track to (some track of library playlist 1 whose persistent ID is p) -- the result is a list (* {file track id 33083 of library playlist id 10591 of source id 46} *) log the_track end tell
iTunes 7.6.1 Released -- Delete Bug SMASHED
Hurrah! iTunes 7.6.1 (available at this writing via Software Update) fixes the AppleScript delete bug.
iTunes AppleScript Delete Bug Moreso
A lister on the AppleScript mailing list writes:
The Scripting Interface Guidelines agree with you: make and delete should be used to create/destroy objects completely, while add and remove should be used to add/remove existing objects to sub-groups. e.g. Compare Address Book, which uses add and remove to add/remove existing person objects to group objects. iTunes predates the SIG, however, and while its scripting interface is fairly extensive it does suffer a number of longstanding design quirks.
Yep. I'd be happy if they just made it like it used to be.
iTunes 7.6 AppleScript Delete Bug
The more I think about the delete issue, mentioned below, the more I think this is a bug and not a feature. I have filed a bug report in any case. Although, I do like that you can trash a file from within iTunes, I do not like that you cannot preserve a track's file. A dandy way for delete to work would be as follows:
1) delete a track from a playlist to just remove it from the playlist.
2) delete a track from its Master Playlist to remove it from iTunes entirely but preserve the file (I tried this hoping it would work, but it does not).
2) delete a track from library playlist 1 to remove it from iTunes entirely AND trash its file.
(I don't know why there isn't a remove command in iTunes, which would make more syntactic sense. The Finder's AppleScript delete command will send a file to the Trash.)
Needless to say, this bug affects several scripts which use delete to remove a track from iTunes without actually trashing the file. For instance, Make Bookmarkable will delete a track from iTunes and then re-add it. Under iTunes 7.6, the track's file is moved to the Trash; when it is re-added, unless the user has "Copy files to iTunes Music folder when adding to library" checked in Preferences, iTunes will presume the track's location is the Trash. Empty the Trash and bye-bye file. This is exactly what is happening to some users.
I can only hope that Apple will see this as a serious bug--it being part of the AppleScript component of iTunes, I am sorry to say that I think it is doubtful--and fix it soon.