Impressive how quickly all this info can popup.

A short summary:
If you want to use large disks (say > 60 GB) there are some issues (some info from the faq, some from this and other threads):
- the standard disk builder is not working well. Use the builder for big disks instead (see the FAQ)
- idem for car2_v2.01_hijack.upgrade if you want to use the 2.01 firmware. There are also versions for the 3.x firmware (see the FAQ)
- if you want to random play many songs (for what many is see below) you have to apply the set_empeg_max_fid.sh 'hack' ( link ). Note that you have to apply this 'hack' each time you update/reload the firmware. In link you can read how to apply the 'hack' if you are not an experienced linux user
- keep the amount of info in the tags of the songs low. You can fill the regular fields (artist etc.), but do not add huge stories to e.g. the comment field. E.g. adding song lyrics is not a wise idea.
This also helps to keep the disk spinning up too often, preventing some noise (only relevant when used at home, not in the car)
- if you have many songs and get tired of the long database rebuilds, it is wise to apply the fidsift.sh 'hack' ( link ). Note that it is wise to apply this 'hack' after each upload of songs. There may be some issues with this 'hack' so read the whole thread
- there may be 'gaps' in the fids list when you delete and add songs quite often. This means that the maximum fid is higher than the counters mentioned below. So, to be sure you can actually reach the maximum, start from an empty disk and only add songs .

Now, what is a 'large' number of songs? This is dependent on the number of songs, the number of playlists per song, and the amount of information in the tags of the songs. There are 3 issues here:
1) The total number of a counter dependent on the number of fids. To do the math, a song counts as 2, the same song in a playlist as 1. So, if a song occurs in 2 playlists it counts as 2 + 1 + 1 = 4 etc.
The maximum number of the counter is 65408, 133194 when 'hacked'. This amounts to 21802 and 44398 songs (divide by 3) if each song is in exactly one playlist
2) The total amount of dynamic data, being the sum of playlists and songs. Dynamic data is dependent on the number of fids. This amounts to a maximum number of songs and playlists of 28,672, 44,099 when 'hacked'. The later number is dependent on the exact way the disk is manufactured, but for large drives in general the number is more or less acurate.
3) The size of the player database, being dependent mostly on the number of songs and the amount of information per song. If the database is too big there is no memory left to run the player software. On a mark 2a player the amount of memory available to the database is about 6 MB. This amounts to (6 MB divided by the number of songs) MB of data per song, which equals the average number of characters per song that can be in the tags. So, keeping the amount of data in the mp3 tags low helps to use a high number of songs.
Older players have less memory so can contain less songs. Does anybody have the exact numbers?

Given that you have a typical large disk of 160 GB with 35.000 songs and 3000 playlists comprised of albums containing the songs, you need the 'hacks' and it might fit:
- it has to fit on the disk ofcourse
- (2 x 35.000) + 3000 = 73.000, which is smaller than 133.197, larger than 65.408. You can even add additional songs or playlists. Note that each song has to be in a playlist since otherwise it can not be found on the player
- if you have a 'standard' disk, 35.000 + 3000 = 38.000, which is smaller than 44.099, larger than 28.672. So it will fit. However, this is dependent on the layout of the disk
- 6 MB / 35.000 = 172 characters per song in the tags. If you use the standard tags artist, title, album, track, genre, and year and clear all other tags you are safe since in general a regular song only consumes in this case half of this amount

Anybody any remarks on this summary? Thanks for the help and the feedback.

Jaap