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.
#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
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
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).
Funnily enough, I actually know of a family with *at least* that many CDs -- probably closer to double.
There are 4 members of the family, each of whom tends to buy ~ 2 cds a day. This has been going on for several (6 or 7) years now.
You should see their sound system(s)!
Rod Taylor
Apple's knowledge base readily admits this. See this link for a workaround:
iTunes 2: How to Overcome 32 000 Song Library Size Limitation
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).