Bug or Feature?
I first posted Scan For Double Entries in 2014 when a strange iTunes issue was somehow allowing two or more track entries to point to the same media file. The script surveys the library for sets of such tracks and then isolates them in their own playlist for further scrutiny; presumably, all but one of these tracks should be deleted.
Anyway, I hadn't updated the script lately because I figured, "Aw heck. That can't still be happening."
The updated version of Scan For Double Entries found 32 sets of two or more tracks where this was still happening—or, at least, had happened and that I hadn't detected 'til now.
The latest version, v4.0, has initial accommodation for macOS 12 Monterey and some UI and security updates. Specifically, it gives you a better idea of what's happening during the search for the tracks, as in the screenshot above. Earlier versions looked like they weren't doing anything during this particular part of the process.
After upgrading today to macOS 11.2.3, I noticed that my scripts and apps that employ the iTunesLibrary framework are having trouble accessing media information. This includes my app "Dupin" and the script "Media Folder Files Not Added" and a small number of others. Affected apps/scripts will likely be unable to complete an initialization routine and stall at "Indexing" or similar stage. I am actively investigating this issue.
UPDATE, March 9, 2021: After several machine reboots (and fsck, disengaging connected devices and so on; the usual start-up regimens), things are now working as expected. I could not say what caused the issue I was experiencing or why it came and went.
When a track is playing in the Music app, Music's AppleScript properties current track and current playlist will be references to that track and the playlist it is playing from. If you have written a script or an app that, for example, displays a notification with the title, artist, album and duration of the currently playing track, current track is who to ask.
Now in Big Sur and Music v1.1, the current track and current playlist will be an "unknown object type" if the track is streaming from Apple Music; this is not a problem if a current track is a local track.
I've already heard from a couple of devs who've run into this issue with their apps and I'm afraid there's no workaround that I'm aware of. The best you can do is account for the error that the call to current track will generate if a non-local track is playing.
I never know if these sorts of things are intentional or not. You certainly shouldn't be able to edit the tags of a streaming track. But I'm not sure why grabbing displayable info—that, to a degree, is otherwise available via "Get Info"—should be hands-off.
The other day I dumped a couple of new AppleScript files into [home]/Library/Music/Scripts/ to make sure they ran OK from there and was surprised that the Music app did not recognize them and that they did not display in its Script menu.
Re-launched Music. Nothing.
Restarted the machine. Nothing.
Now, I am using the latest beta of Music on the latest beta of macOS 10.15.4, so maybe it's a beta thing. However, I've seen this behavior in the past and it generally is resolved by restarting Music. But not this time.
Anyway, if you are seeing the same problem, try installing the script files in the local Library location: [startupdisk]/Library/Music/Scripts/. That worked as expected for me. (I haven't tested this with scripts for the TV app.)
I've been unable to update and release several scripts that use the delete command to remove a playlist because it doesn't behave correctly. Here's a video that shows the issue.
I attempt to delete a playlist. After the script is run each time, the selected playlist is, ostensibly, deleted. However, the Sidebar does not refresh correctly. So that the deleted playlist's title is still listed, and when selected, the tracks of an adjacent playlist are listed instead.
Music will ultimately refresh correctly after being restarted.
In case you didn't know, a track entry in Music (and previously, in iTunes) can have more than one artwork image associated with it. In such cases, the first of its artworks is what I call the "display artwork" and the other artwork is what Apple calls...the "Other Artwork":
The "Album Artwork" image on the left is what is displayed throughout Music/iTunes as the artwork for the track. The "Other Artwork" doesn't get displayed anywhere except in the Artwork pane of the Info panel. And "Other Artwork" doesn't always mean other artwork singular; you can really go to town and add thousands if you want (probably; didn't try; crazy idea). Incidentally, I'm pretty sure only one image can be written a track's file metadata and that will be the "Album Artwork" image.
In AppleScript, a track contains artworks and each artwork is accessed by index: artwork 1, artwork 2...artwork 4732. The "display artwork" is always artwork 1.
I am currently preparing an update to the script Re-Apply Downsized Artwork, which, among other things, can insert a new down-scaled image as a track's artwork 1. If the track already has artworks, they are "pushed up" such that the current artwork 1 becomes artwork 2, the current artwork 2 becomes artwork 3, and so on, so that the new image can become the new artwork 1.
Here's the bug-or-feature part of the essay (mostly bug I'm thinking): When you ask for any other existing artwork greater than 1, Music gives up a parameter error. This makes it impossible for AppleScript to access any artwork data other than artwork 1.
I may release the update to Re-Apply Downsized Artwork that side-steps the "insert" feature, but I thought I'd explain why I haven't released it yet at all.
In case you haven't noticed: If you have downloaded a file from the cloud or have had Music provide artwork, the image data does not get written to the track's file, even though you will see artwork for a track throughout Music.
Additionally, there's no way for an AppleScript to access the artworks of these kinds of tracks.
If the files of your tracks had image metadata before updating to Catalina, then you probably don't have any artwork problems with those.
My specific issue is that files on machine A that have custom artwork I applied to them and that sync via Cloud Music Library do not have the custom artwork when I download them to machine B. Instead, they have whatever artwork Apple has assigned for the album.
I had hoped that there might be an AppleScript trick to workaround this, but as I mentioned above, AppleScript wlll error when attempting access the artwork data or raw data properties of these tracks:
tell application "Music"
set theTrack to item 1 of selection
count artworks of theTrack
--> 1 , accurately detects 1 artwork
get raw data of artwork 1 of theTrack
--> error number -1728
--> error "Music got an error: Can’t get raw data."
You can test this yourself, either with the script or by trying to copy the small artwork image displayed in the top left corner of a track's Show Info window and pasting it somewhere. It won't.
[UPDATE 10.29.19: Hey! Apple fixed many of these issues in the macOS 10.15.1 and Music v1.0.1 updates.]
The bug that some users were experiencing with Catalina scripts from this site has been discovered.
The code was not accounting for variation in system menus. Thus, the "invalid parameter" was an incorrect counting of menu items (the "itemArray").
My Mom isn't even going to care about that. What she and everyone else really wants to know is that I will update and re-post the affected scripts within a day.
I ran across this over the Summer and I forgot to file a bug about until today. When an AppleScript performs delete on a playlist, the playlist is seemingly removed from Music but its name is still displayed in the Sidebar. If you click to select this playlist—that was ostensibly deleted—the view from an adjacent playlist is displayed.
This leads me to believe there's some clean-up or reload that fails to occur. If Music is quit and restarted, the Sidebar of playlists will display as expected; that is, the "ghost" playlist that was deleted will not appear.
Some Correspondents have reported a problem when launching scripts for Catalina. The script doesn't launch and shows this error (screenshot from a Correspondent):
This was an issue that was reported several times during the beta period. I have been unable to replicate the problem myself on any Catalina installation. However, several users who reported it later found that—again, for unknown reasons—the issue eventually corrected itself.
It is baffling. The issue appears to occur during launch when the menu bar for the script is being populated. I'm keeping my eye on it, but, unfortunately, all I can recommend at this point is to check the script again after a few computer restarts.