Slashdot Mirror
iTunes Tops Out At 32,000 Songs
usr122122121 writes "A Macintouch User has discovered that iTunes maxes out at 32,000 songs." I did test this myself (a one-liner perl script to give each file a unique artist/album/title), and it's apparently true. How much it matters is an exercise left to the reader.
I'm sure they'll come out with a patch sometime in the next 12 weeks, 4 days, 21 hours, and 20 minutes.
(Oops, 15 minutes. It took me a few to divide.)
Well, at least the RIAA will be happy...
omnia tua castra sunt nobis
At least I have a goal now... ~1/4 of the way there.
This sig intentionally left justified.
#define MAX_SONGS 32000
arbitrarily.
-Splat
A single iTunes 2 music library can hold 32 000 songs. To accommodate more songs, you can create additional music libraries. Follow these steps;
1. Locate the "iTunes Music Library (2)" file inside the iTunes folder (in Documents).
2. Create a folder called "Backup" and copy the iTunes Music Library (2) file to it. If you make a mistake or change your mind about creating multiple Music Library files, you can go back to using this backup file.
3. Create a folder called "Library 1" and copy the iTunes Music Library (2) file to it.
4. Create a folder called "Library 2" and copy the iTunes Music Library (2) file to it.
5. Repeat for each increment of 32 000 songs. For example, if you have more than 64 000 songs, make two Library folders, if you have more than 96 000 songs, make three Library folders, and so forth.
6. Open iTunes, add, delete, or change the songs in the Music Library for the first 32 000 songs.
7. Quit iTunes, copy "iTunes Music Library (2)" mentioned in step 1 into Library 1.
8. Open iTunes, add, delete, or change the songs in the Music Library for the next 32 000 songs.
9. Quit iTunes, copy "iTunes Music Library (2)" mentioned in step 1 into Library 2.
10. Repeat for each 32 000 increment of unique songs
To access each of the different Music Libraries, copy the respective "iTunes Music Library (2)" file to the iTunes folder (in Documents), replacing the "iTunes Music Library (2)" file that is there. Important: If you accidentally move the file instead of copying it, make sure you move it back to the respective folder, or else you may have to redo some of the setup steps.
http://docs.info.apple.com/article.html?artnum=615 85&SaveKCWindowURL=http%3A%2F%2Fkbase.info.apple.c om%2Fcgi-bin%2FWebObjects%2Fkbase.woa%2Fwa%2FSaveK CToHomePage&searchMode=Assisted&kbhost=kbase.info. apple.com&showButton=false&randomValue=100&showSur vey=false&sessionID=anonymous%7C164541794
"Reality is that which, when you stop believing in it, doesn't go away." PKD
FWIW, I have about a little shy of 2300 songs here, all from CDs that I purchased since 1992'ish...
It's a very modest collection, even for one who doesn't download any music illegally at all. Even then, 2300 songs will play continuously without repeats for more than a week.
If someone would enlighten my ignorant mind: what do you actually do with 32000+ songs, which would play continuously for three months?
Heck, even my measly 5GB iPod holds more music than I can use.
It's perhaps off-topic, but are we collecting data for the sake of the collection? Does it matter if it'd take you three months--without sleep--to actually utilize the data?
As it is, I already have more music than I can actually listen to. For fellow legitimate music users, 32000 songs can easily outlast their lifetime, perhaps the MP3 format, and certainly iTunes'.
So, does it really matter?
I guess it does if you are one of those folks who just download whatever's on kazaa/guntella/whatever today, but for the rest of us with honor, and some taste in music, it really doesn't. 32000 is more than we need.
As usual people quoting an Apple KB article URL forget that they're logged in, etc problem. Here's the public URL: http://docs.info.apple.com/article.html?artnum=615 85 Hope that helps!
"True programmers are artists and someday we'll respect programming as self expression and personal effort." - fateswarm
Respect to pudge for actually taking the time to run a test to verify the story.
Respectable journalism exercised by Slashdot? Is that a pig flying past my window?
The more music you have, the more important it is to have random access to that music. It's no great shakes to find a CD you want to listen to if you have 10 or 100 CDs. Not so for > 1000.
I have roughly 1300 CDs, bought since 1985 (so far, 1081 ripped, which is 13,938 songs). Without random access, finding that one CD that I have a hankering to hear is a nightmare - even with the CDs filed in 8-CD sheets in a lateral file cabinet. With those CDs in iTunes, it's a matter of typing a few letters into the music browser. Do I want to hear a random selection of Grateful Dead tunes? No sweat. Pink Floyd from beginning to end? Easy. Yes, including solo projects by its various members? A little more difficult, but I won't break a sweat.
Almost 14000 (or extrapolating for the rest, 18200) is an uncomfortably large percentage of the iTunes limit of 32000. It's not quite large enough that I'm going apeshit about this, but somebody who had only twice as many CDs as I do would be screwed, for no good reason.
(Advice to others with large collections: buy an external Firewire disk and back your library up!!)
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
Actually, all true arrays are fixed size. I think you mean a sparse array. About the only useful properties of a vanilla array are constant-time indexing and a fixed footprint. You probably are thinking of the Standard Template Library (STL) implementation of a sparse array. While this is nominally part of the C++ standard now, it is not a silver bullet.
.tif file of a fax and then use it in any number of fax jobs. Well, it topped out at 32,000 faxes exactly. Turns out, they arbitrarily limited the job number to this. Interestingly, it was a #define and they coded it so I only changed it one place and it worked. Then I found out that Ext2 supports no more than than 32,768 hard links for a single file (hylafax hard links the .tifs to unique filenames for each job). Even ReiserFS limited me similarly (although it was around 64k). Turns out, until Linux has a 64-bit VFS, this will always be a problem. And backwards compatiblity will be a b*tch when that day comes!
:(
C++ with the STL can still be a pain even if you're careful. Try playing with the STL in large amounts of code. Now try it with no free memory. When you run out of memory, it can get really dicey. Truthfully, it can be very tough to tell when you are allocating memory in C++ (or in what order it happened). Copy constructors can be deceptively well hidden. Same for type conversion functions.
There're always the infamous bugs involving not being able allocate memory to append two string objects to print an error message. That sort of thing is tough to ferret out. I mean, unit testing is one thing but how do you check to see if your program handles running out of RAM well in all situations? Very few languages (or OS's) handle that very gracefully. The hoops that you jump through to correctly through an out-of-memory exception are staggering (pre-allocated RAM, stripped down/in-place string processing, emergency garbage-collection runs, that sort of thing).
I don't disagree that a #define is pretty lame, but you see a lot of this sort of thing and it's not all that bad of a practice. It says:
I acknowledge this is an important problem. This is a stopgap measure. It doesn't solve the problem--it only brings it to light later so that it may be solved appropriately when more fundamental issues have been solved.
I used to think about how call linked lists were because they "never ran out of space" like arrays. Debugging code that failed to allocate new nodes during critical operations changed that.
Since I feel it is relavant, let me relate a little story. I found the same sort of limit awhile back with HylaFAX. You can, nominally, upload a single
Arbitrary limitations like this may be annoying and lame, but they have a very important purpose. They allow you to keep coding on functionality before worrying about scalability. While using a scalable design from the beginning is important, "premature optimization is the root of all evil" (Dr. Knuth).
Five years ago, I would have agreed wholeheartedly. Now, I view this kind of thing to be a fairly good practice. I must be getting old.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
The 32,000 song max is a limit of the Carbon list manager (it uses the 'short' data type for the number of rows). Either Apple will have to update the Carbon framework or move over to the Cocoa framework, which if memory serves, does not have this limitation.
iTunes does not use the List Manager - that's been obsolete for quite some time. List Manager performance degrades drastically when you have a large number of items, and it's limited to 32Kb of data (you could only have 32Kb items if they were 1 byte each in size). Remember that API dates from 1984, when screens were 9" and a list with 32,000 items was pretty unlikely.
iTunes will either use their own internal list structure, or the Carbon Data Browser control. The Cocoa equivalent, NSOutlineView, still had some restrictions before 10.2 (e.g., at most 32Kb children per item).
Apple's knowledge base readily admits this. See this link for a workaround:
iTunes 2: How to Overcome 32 000 Song Library Size Limitation
No one will ever need more than 32000 songs.
You are full of poop! (Or your source is!) Cocoa is as native as the next guy (as long as the next guy isn't Java).
Carbon is a collection of APIs, Cocoa is a RAD framework. Carbon is straight C, Cocoa is Objective-C which (unlike C++) relies on a runtime environment for things such as message passing and polymorphism. Also note that Objective-C winds up getting preprocessed into plain C code before it ever gets compiled. It is no more or less native than C. Finally, the two major compilers for the Mac, gcc and Metrowerks cc, compile both Carbon and Cocoa code fine, although Metrowerks' compiler is rumored to be much better at optimizing for PPC chips.
Cocoa provides you with large amount of functionality "for free", but adds a lot of overhead at the same time. Carbon gives you virtually nothing for free (unless you use CoreFoundation, but that's beyond the scope of this post).
(If you want to argue semantics about APIs and frameworks, just try calling any signifigant amount of Cocoa code from Carbon code. You will get all sorts of wacky side-effects. Now try to call Carbon code from Cocoa code. Oh hey, it just works!)
As a result, less experienced programmers flock to Cocoa, and hence you see a lot of underperforming Cocoa applications. Of course, lots of good programmers put out super-slow Cocoa applications as well, only optimize them later (look at Mail.app). Optimization in Carbon is totally different because you don't have a prebuilt library of objects which may or may not be providing tons of services that you don't need, plus you are in charge of drawing everything and handling your own events. In (an over-generalized) conclusion: Optimization in Carbon is a subtractive process, in which you hone and compact your code into a lean, mean, executing machine. Optimization in Cocoa is an additive process. You can augment existing functionality in a new and streamlined way, or you can add straight C code (or call Carbon!) to replace functionality provided by the (sometimes bloated) builtin objects.
Karma: Incomprehensible (Mostly affected by posting at +5, reading at -1, and metamoderating everything unfair.)
Because Apple didn't write iTunes originally, and it wasn't for OS X.
iTunes was originally SoundJam by Casady & Greene - Apple bought it out, renamed it, gave it that brushed-metal look, and (substantially) continued development on it. This is actually a big part of the reason I don't like it, since I didn't find SoundJam very good and don't like the inherited SJ-isms. That and the brushed metal, anyway.
Since SJ was developed for OS 8/9 and Carbon is the porting API, iTunes is a Carbon app. To make it Cocoa would be a complete rewrite (and pretty pointless - the API isn't all that important frankly).
Wait Wait Wait..
Nope, Still don't care.
Blah Blah Blah.