May 7th, 2012 • 5:05 pm
I have a very large music collection and for years now I have been struggling with iTunes’s poor performance levels. Things have been fluctuating somewhat over time, with some releases being nearly unusable and others somewhat better.
Switching to an SSD drive as my startup volume has also helped somewhat. (There is of course no way that my music files would fit on an SSD drive, so I keep them on a separate conventional hard drive, but the iTunes library files themselves are on the startup volume.)
But I still wish that someone (preferrably Apple) made something like an iTunes Pro. I would be willing to pay for improved performance. Instead, I have little choice but to live with what we have. It’s free, but boy is it a pain in the neck at times.
That said, I recently discovered something that might be of interest to other iTunes users. See, for many years now I have been using the double-click on a playlist icon in the source list to open it in a separate window. I don’t like having to do everything within a single window. In managing my large collection, I often have to view more than one thing at the same time. The only way to achieve this is to open specific playlists in separate windows, using the double-click shortcut.
The problem is that, while this is a built-in feature in iTunes, Apple clearly doesn’t put much effort into supporting it. I regularly encounter bugs associated with the use of a separate window, for example when jumping from track to track from within the modal track information dialog box with the “Next” (command-N) and “Previous” (command-P) button.
But now I have been able to clearly determine something else, which is that trying to edit the tags of tracks listed in a separate window, either in the track list in the window itself or via the track information dialog box, is significantly slower than doing the same thing in the main iTunes window.
This performance penalty also extends to the various AppleScript scripts that I use for automating certain tag-editing tasks. When used with a selection of tracks in a separate window, sometimes they don’t work at all, and sometimes, even when they work, they progress at such a glacial pace that I have time to go and get a coffee before they are done. And yet the same scripts, applied to the same track selection in the main iTunes window, typically perform much faster.
Why? I have no idea. The issue is not the underlying cause(s), but the fact that Apple‘s testers clearly do not care much about performance levels when working with separate windows. Otherwise surely they would have noticed such a difference and tried to get things fixed.
This difference in performance levels is such that I am now pretty much forced to refrain from using separate windows as often as I can. In order to alleviate such a restriction, I find myself creating temporary playlists much more often, so that I can easily switch from one list to another in the same (main) iTunes window, in effect mimicking what I would normally do by switching windows. It’s not as good, of course, since I cannot view the two lists at the same time, but the performance is so much better that living with the restriction is worth it. It’s sad, because I have two large monitors and more than enough screen real estate to display more than one list at a time, but as long as Apple does not fix this issue, I am afraid I will have to continue to live with the restriction to what is more or less a single-window mode.
In addition, I should note that I have also noticed another significant source of performance degradation, which is trying to edit tags while viewing the results of a search. The list of results for a search might look like a playlist that you can work with like any other playlist, but in reality, things like jumping from track to track, bringing up the track information, and so on are, here again, significantly slower than they would normally be.
To avoid this, when I do a search and find what I was looking for, I end up having to exit the search and try and locate the same results “manually”, by browsing through my library. Again, it’s silly that, in 2012, I am forced to do such a thing, but I am afraid the performance gains associated with editing tags with no search active are so significant that I have little choice.
The iTunes Pro of my dreams would handle multiple windows, search results, and other selective “views” of my music collection with no performance penalty whatsoever. Unfortunately, this iTunes Pro does not exist, and the iTunes that currently exists forces me to refrain from using these built-in features of the software altogether.
If you have been struggling with performance issues in iTunes, you might find these tips interesting. They won’t alleviate all performance problems in iTunes but, if my own experience is any indication, they will be a significant help.