December 8th, 2012 • 5:43 pm
In recent years, using iTunes to manage my music library has always been, for me, a major exercise in frustration. The Spinning Beach Ball of Death has always been part of my experience using iTunes.
While some aspects of iTunes’s performance levels have actually improved in iTunes 11 (notably the execution of AppleScript scripts, generally speaking), I am afraid I have to report that, for basic track management and particularly for editing track tags, the user experience has become even more painful for me.
If, for example, I go under the “Songs” tab and, using the column browser, I select a specific album by a specific artist, and then I try to edit the album tracks’ tags (name, artist, album artist, etc.) manually, whether I use the mouse directly in the song list or I bring up the modal track information dialog box for a specific track and then use the “Next” and “Previous” buttons to jump from track to track without having to exit the dialog box, I get constantly interrupted by the SBBOD, to the point that it easily takes me 20 seconds or more to make a simple edit.
As far as I can tell, this is because, each time I make a change, behind the scenes iTunes rewrites the two following files in full:
Given the size of my music library, these two files are respectively approximately 200 MB and 50 MB. Even though my operating system is on an SSD, including my user folder with the “Music” folder which contains the “iTunes” subfolder enclosing these two files (while the actual media files are stored on a separate conventional hard drive), saving a 200 MB or 50 MB file is far from instaneous and, while the saving is taking place, iTunes becomes completely unresponsive (although music playback usually continues uninterrupted) until it’s complete.
And iTunes also regularly creates and then removes temporary files in that same location, an operation which can also cause iTunes to become unresponsive, even in the middle of editing a track tag (i.e. before even pressing the Enter key or clicking elsewhere to validate the edit).
It’s just too painful for words. There are other contexts where editing tags is not as painful, for whatever reason (for example when doing it from within a specific playlist), but this is a basic task and the song list, even with the column browser visible (hiding it does not seem to make any difference), is a perfectly normal place to do it.
I do realize that my music library is somewhat “abnormally” large. I too have encountered the problem described here by Kirk MacElhearn, with the search feature seizing up for 30 seconds or more. Fortunately, other people have found a way to alleviate that particular problem somewhat (by deselecting “Search Entire Library” in the magnifying glass’s pop-up menu), but the search feature too remains slow even when it’s limited to music only.
As far as I can tell, there is no way to alleviate the problem with iTunes rewriting the entire library files every time one makes an edit in a tag. Does Apple ever test its software on machines with more than a few thousand tracks in their iTunes libraries? How can it consider such abysmal performance levels acceptable? Saving these library files is a background process that should take place behind the scenes without interfering with the user experience!
I might be ahead of the pack in terms of the size of my library, but sooner or later, more and more people are going to get to such levels too. And from an engineering point of view, how is it considered elegant or even acceptable to resave a 200 MB file each time the user makes a simple edit, by just adding or deleting a single word in an MP3 or AAC tag?
Fortunately, when I run an AppleScript that modifies the titles of a batch of selected songs, for example by applying or removing word caps, iTunes is able to run the entire script is a single process without being interrupted by the task of saving the library files after each and every edit, but that “background” task does occur sooner or later after the script has run, and also makes iTunes unresponsive then.
In my view, the entire system is badly broken. No matter how often iTunes actually needs to save those library files, it is simply unacceptable that this background task makes the entire application unresponsive.
And I also worry about the life expectancy of my SSD with such a behaviour. There are only so many times that individual “sectors” on an SSD can be rewritten before the hardware starts going bad. I find such frequent rewrites of such large files quite disturbing.