Archive for the ‘Bugs’ Category
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.
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"
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
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 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.
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.
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
set thisPlaylist to user playlist i
if special kind of thisPlaylist is none then
if not (exists track 1 of thisPlaylist) then
It may time-out because the number of actions it has to perform is so large. Just run it until the empties are gone.
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.
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.
Correspondent Roy Gatsby brought this GigaOM article to my attention which discusses a supposed bug in the latest iOS regarding the sorting of TV Shows on iOS devices. Apparently, non-iTunes Store TV Show episodes may not sort correctly if the Artist is not also the Show name. The recommended fix, therefore, is to open up a track’s Get Info window and manually copy the Show tag text and paste it to the Artist tag.
I recommend using the “Put This in That” script from the This Tag, That Tag Scripts collection. It will allow you to copy Show to Artist on a batch of selected tracks.
By the way, changing the Artist tag does not compel iTunes to change the location of the TV Show file since iTunes does not organize TV Shows in the iTunes Media folder by the Artist tag as it does with Music files.
Some AppleScripts from this site use a routine that checks for the version of iTunes you are running. Some of the scripts that use these routines are broken under iTunes 10. So when running a script with iTunes 10.0 you may run into a dialog that erroneously reports something like “This script requires iTunes 6.0.2 or better”. This is not a bug in iTunes, but a problem with the way the script does the version check. (Long story short: the version number once was a number, but more modern versions of apps use a string. Thus “10.0″ is not necessarily greater than “9.2.1″ and the routine fails to accommodate this.) You can edit/comment out the version check routine yourself or wait until I get around to fixing the handful or so scripts that are affected. In that case, let me know if you see the error.
I have received two reports over the past couple of days of some unusual behavior that occurs with iTunes 9.2.1 and some AppleScripts. After running a script that changes the track name tag, the track’s Genre tag is replaced with a number in parentheses, eg, “(10)”. In such cases, it appears that this is a number representing the specific Genre, such that Rock = 30, Jazz = 10, and so on. Like this:
Each report involved a different script which until now presented no problems. Experience suggests that this is not an issue with the scripts (since nothing about the script has changed) but with iTunes.
I have not seen this behavior myself, but I have not yet done any rigorous testing. Since I have only received two reports at this point my guess is that this may be a problem with something else and iTunes; a misconfigured plug-in or background app. But that may be wishful thinking and the problem may indeed just belong to iTunes.
If you have seen any behavior like this please let me know as soon as you can. I’d like as much information as possible before I test and eventually report this to Apple.
[UPDATE: see here for the fix.]