OK, I've spent today investigating these reports and I've concluded the following:

1. If the disk is spun down and you skip track to a relatively high bit rate file (the "relatively" bit depends on how many disks you have and how quickly they spin up) there is a chance that the player won't have cached enough of the next track to avoid a wait when it runs out of data before it can get it from the disk. This won't affect the majority of players since the disk spins up quickly enough. It is exacerbated by files with large ID3v2 tags that were downloaded to the player by a version of emplode prior to beta12c since the ID3v2 data is also cached.

2. When caching occurs small gaps occur very rarely in the music. I believe this is due to contention on some of the locks used by both the audio and the cache. I believe that this is slightly more likely to cause breaks in playback when selecting a new playlist due to the audio buffers not already being full.

I have addressed both issues and inserted some debugging code. If anyone feels that they are in a position to try and reproduce this problem over the weekend I'd like to send out a version containing both the logging and the fixes in the hope that this will provide more information.

If you're interested then please email me ([email protected]) directly.

--
Mike Crowe
I may not be speaking on behalf of empeg above :-)