Bug or Feature?
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.
Over the past few months—I want to say since Mojave's release last year—I have gotten a few reports from users of my artwork scripts regarding a bizarre corruption issue when applying artwork to some types of MP3s.
Essentially, when artwork is applied to the MP3, its file "echoes" the last few seconds of audio data which increases the size of the file. Here is a screenshot sent to me by Correspondent Brandon Pfeiffer, showing the phenomenon in an audio editor (I think it's Fission; no matter, really):
Each "echo" represents a single attempt to add artwork. The new size is reflected in the Size and Time for the file in iTunes as well.
I have not been able to replicate this myself so it has been very difficult to figure out what's going on. However, Brandon did some experimenting and discovered some details. First, it's probably not an issue with the AppleScripts, since Brandon was also able to see this issue when he "manually" applied artwork via a track's Info panel.
Some other observations:
- The source of the MP3s did not seem to make a difference (home rips, Amazon downloads, etcetera)
- The image file being applied may be a factor, its size, type, and so on. However, Brandon could not find a consistent factor in this regard.
- Changing the ID3 version in iTunes had no effect.
- Re-converting a corrupted MP3 to MP3 in iTunes restored the file to its un-corrupted length. (Subsequently adding artwork to such a file, however, eventually corrupted it again.)
- The new file encoded by iTunes did not appear to have the issue at first (the song duration did not change); however, closer inspection using an audio editor (or even just playing via QuickLook in Finder) revealed that the duration had in fact changed, but was yet to be reflected in iTunes.
- Re-encoding the corrupted file using FFmpeg produced several of the following errors: “Header missing - Error while decoding stream #0:0: Invalid data found when processing input”
- Re-encoding the original downloaded source MP3 using FFmpeg did not produce any errors.
Sure beats me. I'll have more follow-up as it develops.
[Update: Several Correspondents have emailed to confirm that they have seen this behavior after manually editing artwork; AppleScript was not a factor.]