You know...my mind is starting to drift around some theories about this. Nothing but speculation at this point...

Every time the empeg starts up, it selects a new area of flash to save it's settings in. This is done to prevent the flash from wearing out. This is done by the kernel.

When the empeg notices a power fail, it goes through several events, one of which is that the data is saved to the pre-selected flash area, hopefully before the capacitor drains and the power fails totally. All of this is also done by the kernel. What is interesting is that in early hardware (pre- 'issue9' ) the kernel used to shut down the display first to conserve power, but in later evolutions the display uses a PIC which requires a relatively slow command to shut it down - hence the display is not shut off until after the flash has been saved. Presumably a screen with a lot of lit pixels requires more energy than a screen with few lit pixels.

I'm theorizing that this problem, and the occasional playlist forgetfulness problem, may both be symptoms of the same issue - the player running out of power before the whole flash area is written. I'm not honestly sure what happens at the next boot if that happens. I presume it reverts to the previously used block.

Now, IIRC, there is a kernel (compile time) debug option that will print "The quick brown fox..." on the serial port as soon as powerfail is detected, so that you can see how long the power lasts. I wonder whether it is worth enabling this and testing to see if this a problem.

Assuming that I am on the right track, why are we seeing this now? Perhaps a recent kernel change has exacerbated the issue. I can't recollect anything that would do that but it can't be ruled out yet. Another thought is that maybe the capacitors (in the PSU section) have degraded such that their capacitance is not as high as when the empeg guys tested it. The temperatues involved aren't considered particularly high though (high temperatures accelerate electrolyte loss.)