Bug or Feature?

June 2 2016 - 10:55 pm

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

May 20 2016 - 7:12 am

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.

May 17 2016 - 12:01 pm

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.]

May 17 2016 - 9:34 am

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.)

May 16 2016 - 4:45 pm

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.

April 6 2016 - 1:56 pm

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 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.

January 21 2016 - 7:52 am

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

December 30 2015 - 7:48 am

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.

December 3 2015 - 3:57 pm

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.

October 21 2015 - 4:21 pm

iTunes play with once is Broken Redux

I posted about this back in July but the problem seemed to go away (which is weird, too).

To play a track just once and then stop you use the once modifier with the play command:

tell application "iTunes"

set aTrack to item 1 of selection

play aTrack with once

end tell

As I said, I first noted this in July when iTunes 12.2 came out. But then I somehow couldn't get it not to work. Also saw a mention of it on the AppleScript mailing list, but even then I got it to work. Well, I definitely can't get it to work now. Filed a bug.

UPDATE: Ah-HA! It will work if the Up Next queue is completely empty, which can be made so by clicking its "Clear" button.

Site contents © 2001 - 2019 (that's right: 2001) Doug Adams and weblished by Doug Adams. Contact support AT dougscripts DOT com. About.
All rights reserved. Privacy.
AppleScript, iTunes, iPod, iPad, and iPhone are registered trademarks of Apple Inc. This site has no direct affiliation with Apple, Inc.
The one who says "it cannot be done" should not interrupt the one doing it.