iTunes Match AppleScripting Notes Redux

iTunes 10.5.2 appears to fix some issues I was seeing regarding AppleScripting and iTunes Match. In 10.5.1, AppleScript occasionally wouldn't recognize that a track had "morphed" from shared track to file track—say, after downloading a file from the cloud—and visa versa without restarting iTunes. This is fixed and AppleScript detects the change of class immediately.

Also, attempting to delete an iTunes Match file track from the library will no longer elicit the alert dialog requiring confirmation to remove the track from the cloud; the track will simply remain in the library as a shared track and will remain in the cloud. Its file remains in its original location (although its local file path can be retrieved via the track's location property and used to move, Trash or rm the file if necessary). For obvious security reasons, AppleScript cannot delete a track from the cloud or completely delete an iTunes Match track from iTunes. This kind of removal can only be done manually by the user.

I should note that a script probably should remove the file when deleting an iTunes Match track from the library (that is, library playlist 1; deleting from an ordinary user playlist simply removes the track from the playlist, as expected). Otherwise, re-downloading the file from the cloud will create a duplicate file.

On another note entirely, I'm seeing artwork now appearing again as a track's file's Finder icon. Since iTunes 10.4 artwork behavior has been—as one tweet to me put it—"hinky" in this regard. I don't pay much attention to artwork so this may have been fixed in 10.5.1 or perhaps is an iTunes Match phenomenon.

More as it develops.

(UPDATE: Several Correspondents have reported that artworks were showing up as Finder icons again as of 10.5.1.)