Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedBug or Feature?
Issue With Copying a Newly Converted File
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
end tell
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.
The player position Bug Fixed
This bug that prevented setting the player position while the player state is paused is fixed in iTunes 12.4.1
Slight Growing Pains Continue
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 player position Can Fail
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
end tell
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.]
Music vs music
The AppleScript issue in iTunes 12.4 whereby filtering special kind by Music fails is caused by a conflict with the new media kind property. One of the values it uses is music.
Bugs are being filed. (Hat-tip to Correspondent Nate Weaver.)
Busted: special kind syntax?
In iTunes 12.4, I can't get a reference to the Music library playlist by doing this:
tell application "iTunes"
set musicPlaylist to (get some playlist whose special kind is Music)
end tell
...because iTunes apparently doesn't recognize the Music value for special kind. When the script is compiled it changes the Music value to lower case:
tell application "iTunes"
set musicPlaylist to (get some playlist whose special kind is music)
end tell
...and the script fails. A lot of my scripts use this to target a particular media library, like Music or Movies.
I suspect, (maybe? perhaps?) that the new select command is related? But, until now, I haven't been able to get any object to react to select. More as it develops.
UPDATE: Well, this works (coercing the value of special kind to text), but it shouldn't have to be done this way:
tell application "iTunes"
set nonSpecial to every user playlist whose special kind is not none
repeat with aP in nonSpecial
if (special kind of aP as text) is "Music" then
log "HEY"
end if
end repeat
end tell
UPDATE ALSO: Correspondent Nate Weaver tweeted to remind me that the event code «class kSpZ» can be used instead of the boinked Music value.
UPDATE ALSO ALSO: Here's the problem.
Play Counts Bug
There seems to be a fairly recent bug affecting track play counts--or plays--when the played count property of an iTunes track is changed with AppleScript. If iCloud Music Library or iTunes Match is enabled, the value will revert to what it was before being changed by AppleScript. It seems as though either the new play count for a track doesn't get synced to the cloud or that the original value in the cloud has over-written the new plays value. Or something like that.
Several scripts here (Multi-Item Edit, New Play Count, New Last Played Date, et al) that allow you to edit the play counts of your tracks are affected by this bug, which only occurs if you're also using iCloud Music Library or iTunes Match. I am not sure if versions of iTunes prior to 12.3.3.17 are affected or if, perhaps, the bug also occurs with a track's skipped count (I wouldn't be surprised).
I filed a bug report with Apple and it turns out it's already an open issue, so Apple knows about it. Now we wait.
EPPC Bug? Probably Not
Not long ago, a user reported an issue using the EPPC protocol to access AirPlay properties of iTunes on a remote machine. To keep a long story short, it doesn't appear to be a bug. The user neglected to incorporate a "using terms from" block. I should have known at the time that this was a likely omission. This is an example how the code should be implemented:
tell application "iTunes" of machine "eppc://user:password@Remote-Machine.local"
using terms from application "iTunes"
set apDevices to (get name of every AirPlay device whose available is true)
end using terms from
end tell
EPPC and AirPlay Bug?
A Correspondent alerted me to an issue he is seeing, and that I can verify, using the EPPC protocol to access the AirPlay device property via iTunes on a remote machine. For example, with Remote Apple Events enabled on a remote machine, a script like this—that up until recently worked—will fail:
tell application "iTunes" of machine "eppc://user:password@Remote-Machine.local"
set apDevices to (get name of every AirPlay device)
end tell
In this example, you would expect to get a list of the names of the AirPlay devices available on the remote machine. But instead, the script trips up on the word "AirPlay" with the error "Expected class name but found identifier". "AirPlay device" is a class name. Other conventional iTunes/Remote Apple Events routines work as expected.
Our Correspondent reports that this sort of script worked happily in the past; sounds like he uses it to control iTunes like a server on the remote machine. There have been EPPC-related bugs in the past that were introduced with Security Updates so I'm hoping this is one of those sorts of things and not a deliberate "security feature". File a bug if you can.
Track Numbers in the Thousands
A Correspondent who uses my applet Multi-Item Edit to enter five-digit track numbers has reported that iTunes now formats these numbers with a comma; for example, 16789 becomes 16,789. iTunes itself will only allow three digits to be entered in the Get Info track number field, so it is unlikely that most users would ever encounter this. According to my Correspondent, this is a relatively recent iTunes behavior.
It's not like track numbers are "counting numbers". They're more like digits. Is that the arithmetical name for that sort of thing?
Multi-Item Edit is able to enter more than three digits because the AppleScript track number property accepts integers and I guess nobody ever thought of limiting the input to less than 1000.
Interestingly, track numbers used to only go to 99 because that was the Red Book-limited number of audio tracks allowed on a CD. Thus the original ID3 Tag spec only allowed two digits for track numbers. Because, the thinking at the time went, why would there ever be a need for more? Although I recall that you could "fake" more tracks using CD track indexes. I'm not sure what the spec is now since there's no such thing as audio files anymore. (Just kidding. Been reading too many tech articles on streaming lately.)
I'm going to file the comma issue as a bug just to be ticky-tacky about it, but—also interestingly—the episode number tag does not use comma formatting and it also only accepts integers, at least as far as AppleScript is concerned (you can see the track row at the top of this screenshot):
As I mentioned, it's unlikely most people would ever notice this, but you might if you were taking advantage of this greater-than-999 kludge with AppleScript.
