Okay, you know the bug where sometimes Hijack misses playing the startup animation? Instead of playing the startup animation, we see "Hijack v263 By Mark Lord" for a long time, followed by the custom logo.

I had it happen to me today, and I noticed something else about it that I hadn't noticed before.

When it finished booting, it began playing the song from the power-pull before the last power-pull, rather than from the one right before. In other words, it happened after the player had failed to write the flash like in this FAQ entry.

Does this help to track down the source of this rare and intermittent bug?

A HAAAA!!! I KNEW i wasn't going crazy. Mines been doing this A LOT lately, forgetting the song position... but i thought i was having Deja Vu or something. It seems to happen intermitently though... not every time i pull the power. I'm going to be watching it like a hawk now to see when it happens.

Phew... i thought i was going nuts.

/me wonders if the button LED hack could be to blame.

The first thing that the empeg does when it detects a powerdown event is to kill the display to conserve power. I wonder if we do the same for the LEDs?

I'll take a look later.

Interesting theory. The LED hack is definitely something that Loren and I now have in common.

Nope... this is on my un-LED-hacked empeg. So nogo on that theory.

For the first time I saw this one using v258 yesterday. So apparently this bug does exist outside the bounds of Tony's honda. It's very intermittent, and not all that distressing when it does happen.

I would personally prefer Mark spend his Empeg time on new enhancements (especially to the userland app interface) rather than chasing down this rather benign bug.

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

I did think about killing LED power on "emergency shutdown", but the act of sending the command to the LEDs takes longer than the entire power loss + flash-save scenario.. so a no-brainer there.

Cheers

Yeah, I realised that before I got to look at it which worried me for a minute - until I realised that as we don't all see this problem consistently with the LEDs enabled it must be a non-issue.