Okay, here is my best guess at what might be causing this.

I'm betting that once in a while, the flash state restore code in empeg_state.c has to do a full "block erase" of the saveareas. This probably takes a while (not sure how long.. need to time it), perhaps more than a tenth of a second or so.

This then causes the animation scheduling to be out of whack, because the jiffies suddenly get incremented by a huge amount all at once. This makes our timeout for the next (first) animation frame appear to be some distant time in the future, instead of within the next couple of jiffies.

Thus, the behaviour seen (by some).

Plausible? Yes. Note that this kernel behaviour would be a BUG, and is quite possible on the Empeg since the empeg timer code is vastly simplified over that from other ports of the Linux kernel.. and in the course of simplification, this bug may have been introduced.

The solution for our immediate issue I suppose, would be to ensure that the first animation frame is scheduled far enough into the future to allow for a full block erase of the flash saveareas, which slows down the animation, but which also ensures we don't get the timer wraparound.

To this end, I'll crank out a new version v265 this morning, which delays the animation start by a little bit, just to see if it clears things up. A side effect may be that you'll see a pause at the beginning.

Gimme half an hour.

Cheers