Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedBugs
Duplicate Purchases Syncing Bug in iTunes and iOS 8
Rob Griffiths (of Many Tricks and founder of Mac OS X Hints) had a rough couple of days this past weekend trying to get his new iPhone 6 to sync with his iTunes library. It just wouldn't. He writes about the ordeal in "An iPhone 6, (no) movies, and me".
It turns out, as Rob reports in a follow-up, "A nasty little iTunes/iOS bug may be causing media sync issues", that there's a bug in the pipeline between the current versions of iTunes and iOS 8. The syncing may stop if you have duplicates of purchased media files.
At first, Rob tried using iTunes' "Show Duplicates" tool to locate any duplicates. But it didn't find every duplicate track entry (it's not very rigorous, even using "Show Exact Duplicates"). He then turned to my duplicate managing app Dupin and was able to find the dupes by jiggering the Criteria settings to find album tracks with the same track number—matching using the name of the tracks failed because the duplicates had slightly different titles. (I'm pretty sure iTunes' "Show Duplicates" always considers the name of the tracks.) Once he eliminated the duplicates the syncing went fine.
I must admit, this doesn't affect me and I hadn't even heard about this issue until now. Of course, it's still early days with iOS 8 adoption.
AirPlay Scripting Bug Fixed in 11.1.2
The bug affecting AirPlay scripting has been fixed in iTunes 11.1.2.
iTunes 11.1 Breaks Some Airplay scripting
[UPDATE: iTunes 11.1.2 addresses and fixes this issue.]
The latest version of iTunes breaks some scripts I posted when Airplay scripting was introduced back in the Spring.
Specifically, an error will be generated doing something as simple as this:
tell application "iTunes"
set apDevices to (get AirPlay devices)
end tell
Come on. It's gotta be a bug, right? You can still get properties of AirPlay devices and set the current AirPlay devices property by device name:
tell application "iTunes"
set apDevices to (get name of AirPlay devices)
--> {"Computer", "Doug's AirPort Express"}
set current AirPlay devices to AirPlay device "Computer"
end tell
Waiting to see how this evolves.
iApps.plist Issue?
As you may know, the location of the current iTunes library's database files can be read from a user preferences file named "com.apple.iApps.plist". This preferences file also maintains the location of the current iPhoto library and perhaps the locations of other apps' support files. By default, the location of the current iTunes database files is in ~/Music/iTunes/, like in the screenshot below. If or whenever you select or create a new library by Option-launching iTunes the location you select is stored in the iApps.plist as iTunesRecentDatabasePaths. Third-party apps can then locate the current database by simply reading the meta data from the iApps.plist.
Recently, since the launch of iTunes 11, I've been hearing from Correspondents who report that some of my software (apps and scripts) that need to access the iApps.plist are no longer finding the iTunesRecentDatabasePaths data. In fact, their iApps.plist file does not even contain the data. Somewhow it has not been updated correctly. Thus, when an app or script tries to read the iApps.plist it fails with a Console error like "The domain/default pair of (/Users/SomeUser/Library/Preferences/com.apple.iApps, iTunesRecentDatabasePaths) does not exist".
The fix is, first, to make sure you note the location of your iTunes support files. If you've never used the Option-launch method of creating a new library then this location is your home folder's "/Music/iTunes/" folder. Otherwise, well, I suppose you know where you created a new library. Now, quit iTunes. Hold the Option key and launch iTunes again. In the dialog that appears click the "Choose Library" button. Navigate the Open dialog to the folder you just noted (it will contain an "iTunes Library.itl" file and one or the other of an "iTunes Music Library.xml" or "iTunes Music.xml" file) and click the "Open" button. This should write the location to the iApps.plist correctly allowing scripts and apps to read it without error.
Go to Current Song and reveal Busted in iTunes 11
The menu command "Go to Current Song" (in the Controls menu of iTunes 11) indeed shows the playlist that the current song is playing from, but it does not select the current playing track. The Command-L keyboard shortcut no longer works either. Looking for an AppleScript workaround, I found that reveal current track behaves the same way. The reveal command still selects a playlist, eg: reveal current playlist.
Update: Apparently these fails happen when a song is playing from a playlist but it's OK when a track is playing in the Music library.
Update 2: Here's a script that will reveal the current song in the Music playlist no matter where it is playing. Be sure to give it a shortcut.
tell application "iTunes"
activate
try
set dbid to (get database ID of current track)
set musicLib to some playlist whose special kind is Music
set theTrack to some track of musicLib whose database ID is dbid
reveal theTrack
end try
end tell
Obviously, this doesn't help get you back to the current playlist. But if you need to access the playing track for some other reason then it'll do. You can always right-click the LCD and access the current track's Get Info, Show in Playlist, and so on.
Update 3: Kirk has an important observation on this issue.
Update 4 (December 16): This appears to be fixed in iTunes 11.0.1.
iTunes 11 AppleScript bug
iTunes 11 breaks the AppleScript command to shuffle a playlist. The value of shuffle can still be read with get, it just can't be set.
Update: song repeat is broken in the same way.
Update 2: shuffle and song repeat will only return a value of false and off, respectively. Thus, in addition to being unable to change these values for a playlist, a script cannot detect the actual state of these settings.
Find Truncated Tracks
So there's this problem with iTunes Match whereby a downloaded file is unable to be played all the way through. My friend Kirk McElhearn describes the problem in great detail here. Essentially, the iTunes Match file is downloaded but some kind of corruption in the file prevents audio data from being read/played all the way through to the end even though all the data is very likely extant. If a truncated track and associated file are deleted it can be re-downloaded intact successfully. But it is difficult to hunt these tracks down since the reported duration, start, finish, size and time values of the tracks are correct and there is otherwise nothing detectably unusual about them.
The only way to discover if a track is truncated is to play it and hear it end abruptly. Since it appears that less than half the audio data of these tracks is playable, I found that by starting to play the track after positioning the cursor very close to the end of the track in the iTunes LED window the next track would play immediately if the clicked-on track was truncated.
So I've written a script, Find Truncated Tracks, that automates this process for a playlist of tracks and copies the varmints to a discrete playlist for later recycling. Find Truncated Tracks will go through the tracks in the current playlist starting with a single selected track. It will position the play head at ten seconds from the end of the track. Then, it will play the track and immediately check the player position. If the track is truncated, the player position will be the last playable second of the track which will be much sooner than the ten-seconds-from-the-end play position at which the track was just set to start. Thus detected, this truncated track will be copied to a new playlist named "_Truncated Tracks". And so on for each track in the playlist from the selected starting track.
Unfortunately, it's not terrifically fast. Each track must be played in real time so that the script can detect if it can play all the way through. Fortunately, a track only needs to play for a fraction of a second to get its current player position. But still, the script's not going to finish up instantaneously. Average running times at my house were about three minutes per thousand tracks.
Play counts are not affected.
You may run into a dialog that will popup for unauthorized purchased tracks (if you have any of those). AppleScript can't prevent this, so that may put the kibosh on unattended use. Otherwise, just let it run and go out for a sandwich.
Thousands of Empty Playlists?
I've been hearing of an iTunes Match glitch that somehow or another creates thousands of empty playlists. Here's a script that will delete every empty playlist:
tell application "iTunes"
set y to (get index of last user playlist)
repeat with i from y to 1 by -1
try
set thisPlaylist to user playlist i
if special kind of thisPlaylist is none then
if not (exists track 1 of thisPlaylist) then
delete thisPlaylist
end if
end if
end try
end repeat
end tell
It may time-out because the number of actions it has to perform is so large. Just run it until the empties are gone.
Artwork-Related Scripting Bug Follow-Up
Not long ago I posted about a possible bug introduced with iTunes 10.2 regarding reading PICT file data for use as track artwork (Possible Artwork-Related Scripting Bug in iTunes 10.2?). Essentially, a tried-and-true AppleScript routine for importing PICT image data fails in iTunes 10.2. After some investigation, it turns out that iTunes 10.2 now uses ImageIO for all image handling instead of QuickTime and the ImageIO framework no longer supports PICT files. No one should really be surprised since the PICT format has largely been deprecated. But even so, until recently, PICT was still supported in iTunes.
So it's not a bug but a side effect of modernity.
The fix for iTunes 10.2 and above is to simply read in the data from a PNG or JPEG file:
tell application "iTunes" to set data of artwork 1 of theTrack to (read (file targetImageFile) as picture)
Where theTrack is a reference to a file track in iTunes and targetImageFile is the path to a valid PNG or JPEG image file.
A couple of my scripts that need the fix will be posted later today.
Possible Artwork-Related Scripting Bug in iTunes 10.2?
Several users have reported, and I can verify, that an AppleScript routine used to apply image data to a track as artwork fails with an error -206 when used on iTunes 10.2. Essentially, the error is tripped when the following code--or similar--is run; theTrack is a reference to an iTunes file track and thePictFile is a valid PICT image file:
set data of artwork 1 of theTrack to (read (thePictFile as alias) from 513 as picture)
There are a couple a scripts here that use a variation of that (Re-Apply Downsized Artwork is one) and thus they will error when run with iTunes 10.2. The snippet works fine in versions before 10.2. I can use it on v10.1.2, for example. It might be a bug so I'll keep my eye on this.
