I'm running 9c+ and I got into a mode while listening where it would continue to advance but there was a stuttering every 0.75 seconds (seemingly). Skipping to the next song or repeating the prior one didn't make the problem go away. I didn't try stopping and starting, I made the mistake of resetting by pulling the device out of the dock and putting it back (and everything returned to normal).

All my music is ripped with MusicMatch @ 80% VBR (~160Kbits/sec). This causes confusion with the time-remaining calculation as well as causing the drive to keep spinning 90% of the time instead of 25% of the time.

This bug has been around for a while, and is also documented here:

http://empeg.comms.net/cgi-bin/showpost.pl?Board=bigs&Number=404&page=1&view=collapsed&sb=5

Another one of those things that needs to be nailed down before consumer release.

Corby
6-Gig Blue, #320

I experienced this bug for the second time ever. The first time I did what most others did, and pull the power. Tonight it happened while I was in the car with my laptop sitting at a shell. I exited out because I was done, and got the stuttering sound. (Visuals were not on since I'm running 10a). Since I had the laptop still connected, I hit Q to cause the player to exit, then exited the shell. The player worked fine after that, so the bug is definitly in the player and not the kernel. This is only the second time I have seen it since owning my unit, so it's not a major problem, just something good for one of the programmers to look into when they get done with something else.

My empeg site is:http://24.236.3.131/empeg/

This confirms my understanding of the fault. I believe there is a race condition with the starting of the various threads within the player which very occasionally causes this behaviour. I believe it is probably something to do with caching although this is only a hunch.

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

Thanks, Mike. Glad to know you're on top of this one. I've had it happen occasionally, too, and it would be good to know if it gets fixed.

Question: I've heard the term "Race Condition" recently used by other programmers when referring to certain software faults. In all my years of programming, I've never heard the term until this year. What does it mean?

Tony Fabris
Empeg #144

It's the cousin of the condition called the deadlock. In a deadlock, two or more processes vie for temporary ownership of a resource, and the first one of them gets it and never relinquishes it to the other processes because the first one has been waiting for the other ones to get it in the first place effectively bringing everything to a dead lock / halt.

A race condition is similar, two or more processes race to obtain an important resource, and this is a resource that can only be used reliably by one thing at once. And somehow, through some blooper, two or more processes grab hold of this resource and very unpredictable things begin to occur, because they are both attempting to mess with this resource without knowing something else is also messing with it.

Thanks for that explanation. So it's the sort of thing that usually only happens with multithreaded code. I get it.

Tony Fabris
Empeg #144

It can also happen with event driven code. Especially stuff that causes pre-emption of a line of execution, and one stack state owns a resource, it pops out, the second stack state grabs it, now there are two states holding the same resource, and either a deadlock or a race condition occurs.

Calvin