Bug or Feature?
iTunes 12.7 introduced the “Downloaded” playlist that can be made accessible in the Library section of the Sidebar. Ostensibly, this playlist contains all the tracks you have downloaded in one way or another from the Apple Store, iCloud Music Library and Apple Music.
Unfortunately, the Downloaded playlist is inaccessible to AppleScript. The following script should 1) get a reference to the selected playlist and 2) get a reference to the selected tracks, but it does neither:
Thus, any script that needs this information to work with the Downloaded playlist will fail.
A couple of Correspondents have reported that fresh installations of Sierra do not have a “iTunes” folder in the User Library folder (~/Library/iTunes/). Traditionally, this folder contains the “iTunes Plug-Ins” folder and the “Scripts” folder (see my Download FAQ page for more details). Additionally, some third-party apps may use this folder for caching their own iTunes-related files. However, the “Scripts” folder is not created automatically and needs to be created by the user; and I believe Apple has lately inhibited the use of third-party visualizers such that the “iTunes Plug-Ins” folder may no longer be necessary. Perhaps, therefore, the ~/Library/iTunes/ folder is not created automatically anymore either.
To repeat: this seems to affect clean installs of the latest Sierra and iTunes 12.6 and later. If you already have these folders configured on your machine they will not disappear when you upgrade the operating system—at least, that’s been my experience.
iTunes still looks for AppleScript files in this location to make them available in its Script menu, so if your system isn’t configured with the ~/Library/iTunes/ folder you will have to create the intermediate “iTunes” folder there and then the “Scripts” folder within it.
AppleScripts can also be installed in the /Library/iTunes/Scripts/ folder—that’s the [startup disk]/Library/ folder and putting AppleScripts here makes them available to all Users. Again, the “Scripts” folder may have to be created by the user.
AppleScripts will appear in the system-wide Script menu in the Menu Bar when they are installed in ~/Library/Scripts/Applications/iTunes/ for the single User or /Library/Scripts/Applications/iTunes/ for all Users.
Not too long ago, a version of the iTunes scripting definition used the new value “music” for the media kind property. Unfortunately, this caused confusion with the similar “Music” value for a playlist’s special kind property. This was eventually fixed such that “song” was used instead of “music” for the media kind property. All’s well now, right? We’ll never see a mistake like that again, right?
Never say never.
It happens that “songs” is an enumerator value for the search command as well as for the new shuffle mode property. And, unfortunately, when “songs” is used as the search command’s only value—eg: search somePlaylist for “my search text” only songs, indicating that one wants to search just song titles—some kind of ambiguity issue causes a reversion to the default all value. Thus, every tag is searched for the search term instead of only the song titles and you’ll get a lot more search results than expected. For example, in searching my Movies library for “Big”, I not only got “The Big Lebowski” and “The Big Chill”, but a bunch of other movies that had the word “big” in their description tag.
Ironically, a search of the scripting definition file may have caught this before “songs” was re-purposed for shuffle mode.
This affects at least one script of mine, Search Results to Playlist, which I’m fixing with a silly workaround using hard-coded enumerator codes in a run script handler. Yech.
Kirk wrote about missing artist photos in iTunes for one of his Macworld columns recently. This is an effect that was introduced in iTunes 12.5 and the iOS 10 Music app. It is disappointing to have so many microphone logos and tiny artist photos in one’s library.
Several correspondents have inquired about fixing this with some kind of homebrewed kludge, but I’m afraid not. Artist images are handled internally by Apple and the iTunes/Music apps. There is no “artist image tag” or hook or cache or anything like that such that images can be supplied by the user.
(This post has been updated, see below.)
A Correspondent emaIed to point out that when text is entered in either the new Work or Movement Name tags and the text contains non-English characters they do not render correctly in Albums and Artists Views. Nor in the Info window:
So, watch out. This may be a display issue but I am not sure if Apple can fix it at their end or an update to iTunes is required.
UPDATE: FWIW, this is how it looks in the XML. Note that the Name tag is fine, but not the Movement tag:
UPDATE ALSO (September 16, 2016): This issue appears to have been resolved today after re-entering Work and Movement text.
UPDATE MORE (September 16, 2016): Spoke to soon. If the track is played then the NULL character returns. (Is that what that diamond-question mark character is called? Been a long time since I’ve seen it on webpages.)
I’ve been going crazy trying to track down a problem using AppleScript to convert a file and then duplicate the newly converted file’s track entry to a playlist. No matter what I tried, the original pre-converted track is copied to the playlist and not the new converted file. Here’s a stripped-down example:
tell application “iTunes”
set oldTrack to item 1 of selection
— convert oldTrack and get a ref to the newTrack
set newTrack to item 1 of (convert oldTrack)
duplicate newTrack to somePlaylist
— …but oldTrack gets copied
Come to find out, iTunes 12.4.1 gets fussy about converted files when iCloud Music Library is active. As soon as the new converted file is created (again, via AppleScript) and added to the library, iTunes goes into its “Waiting…” mode—waiting to upload the file to the cloud. This apparently prevents AppleScript from doing anything with the new track entry.
This reminded me of how iTunes will warn you about editing a track (that is, about using Get Info) while it is waiting to be uploaded:
Strangely, all the properties for the new track are available. So, I tried adding it to the playlist using its location (file path); I tried persistent ID‘ing it from library playlist 1 to get a reference to it; neither worked.
It wasn’t until I shut iCloud Music Library off in iTunes > Preferences… > General that a newly converted track entry could be copied to a playlist. After some more experimentation with iCloud Music Library turned back on, I tried setting up a loop that waited for the cloud status of the new track to change to uploaded. But, since it can take several minutes for this process to be initiated, I abandoned this.
Primarily this will be a problem for Quick Convert, which has an option to copy converted tracks to a new/selected playlist (and, I suppose, any other script that works similarly):
If iCloud Music Library is ON, the “Copy new tracks to playlist:” option is ineffective.
This bug that prevented setting the player position while the player state is paused is fixed in iTunes 12.4.1
The podcast value for media kind will confuse older scripts that look for the podcast property of track. The podcast property for track (“is this track a podcast episode?”) was removed in iTunes 12.4. Similarly, the iTunes U property of track has also been removed and is now a value for media kind.
Setting the player position while the iTunes player state is paused resets the player state to stopped and resets the player position to 0.
tell application “iTunes”
play — initialize the state to Play
pause — put iTunes in Pause mode
set player position to 5
log (get player state) — will be stopped
log (get player position) — will be 0
Attempting a workaround, I found that as long as the track isn’t paused, the player position can be set.
This did not occur in previous versions; setting the player position while paused would, as expected, move the play head to that position. In fact, Needle Drop uses a variation of this to begin playing a track at a user-set start time. Needless to say, this won’t work with iTunes 12.4. (Hat-tip to Correspondent Rob Robinson.)
[UPDATE: Needle Drop v5.3 addresses this issue.]
[UPDATE ALSO: this issue is fixed in iTunes 12.4.1.]