I thought I'd found the problem;
I copied the prefs file to the new installations without editing the path. 

But even after fixing that and a full rescan this problem continues.

I see this is marked fixed - Was there a problem or am I stupid? 
Is it safe to try again with a later version?

reopening - this isn't fixed as far as I can tell. 
Have downloaded last night's release (25th) and done a completely clean install.
Selected 'use iTunes' in server settings and waited for rescan to complete.

Add a playlist to a player and all tracks are skipped with the error above.

Checked d_info output, File Size etc is populated:
2005-07-25 20:02:18.4818 New track for
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3
2005-07-25 20:02:18.4829 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : FS to
9058959
2005-07-25 20:02:18.4837 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : YEAR to
1998
2005-07-25 20:02:18.4843 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 :
TITLESORT to ST
UKA SEVEN
2005-07-25 20:02:18.4850 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : SECS to
422.53
2005-07-25 20:02:18.4856 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : TITLE
to Stuka
Seven
2005-07-25 20:02:18.4862 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : CT to mp3
2005-07-25 20:02:18.4871 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 : BITRATE
to 1710
00
2005-07-25 20:02:18.4878 Adding
file:///E:/Compilations/Jockey%20Slut%20JUKEBOX/04%20Stuka%20Seven.mp3 :
TRACKNUM to 4

I wonder if the problem is the location of my music - E:/ - there are a number
of posts in the forum from people having trouble with drive letters. This has
always worked before though.
(am running SlimServer from command prompt, not as a service)

This is a 6.2 thing, I'm sure.  the new (experimental) itunes parser is mixing
things up a bit.  I can certainly reproduce this in 6.2. 

wiht 6.1.1, I have not seen this.  Please ERASE your db file (wipes entire db
structure, instead of just wipe cache which only clears the tables)

6.1.2 is working OK for me. 
Problems there must have been down to me mucking up the config files.

possile.  6.2 also changes the pref file to YAML instead of the old raw
key-value text pairs.  Going back will mix those up as well. 6.2 got dumped with
a lot of experiments (long held waiting on local copies) after 6.1.x was branched.  

not sure about the dates.

sorry, that target should have been 6.2

updated Summary - as it seems like this is iTunes only problem? 
I scanned some music in the normal manner and could play it.

I have done a completely clean install of 6.2 and the problem persists so not
config file related.

Also noticed that iTunes scan is not enabled by default - in 6.1 I believe it is
if iTunes is detected?

songs seem to be able to play at song level.  This appears to be similar to the
bitrate problem that killed 6.1 so fast.  At the album or artist level, all the
items are lightweighttracks, which dont have audio_size info, so the playback
dumps for tracks with zero size or duration.

I think I know why this is happening, for real now.  iTunes plugin requires
readtags = 1.  in handleTrack(), the update is settings readTags to 0.  I did
thia argument before.  apparently, itunes doesn't provide enough info on its own
for slimserver to be able to play back music with all the pedantic precision
required.  Thus, it must ALWAYS readTags to get the real audio size (not file
size), offset, etc.  Without this, it will fail.  In theory, using iTunes with
MusicFolder will be ok, but iTunes on its own leaves everything unplayable.

Changing line 789 to read:
'readTags'   => 1,

should do the trick.

yes this came up last time. 
What is it SlimServer needs that iTunes doesn't give?
Surely would be vastly faster if you didn't need to scan the files!

yes, it would, but I've done this argument to death already and lost.  with the
file size info that itunes provides, without any offset for the header,
slimserver will pop as it plays metadata.  if slimserver were in the position to
dictate formats, it would be different, but instead it has to suffer from
dealing with every crazy combination of format and header style/length.

regardless, dan fixed this with change 3801.

thanks for the info! fingers crossed.