We've explained why it happens, and made progress on beta 10, but we have serious problems replicating the problem, which means we can't do any more to fix it. We're happy the timer code is fixed in the kernel now, and we're happy the state machine behaves correctly to recognise the buttons. The only variable is interrupt latency, which isn't exactly easy to characterise.

The code in the mk2 front panel processor has been altered to send two button-up codes every time a button is released to try and improve robustness. The rotary control does send button presses, but as this sends one for left and one for right, there's no way you can get runaway - only (worst case) a missed "click" on the rotary dial - something which the Sony & Blaupunkt head units we have in the office suffer from too if you turn the controls too fast.

We've done all we can unless we have a foolproof way to replicate the bug. We don't see it anymore here, even under extreme circumstances. I've not seen the bug despite spending 8 hours on the road over the weekend (& using the volume control maybe 30 times in that period). It's not a common reported problem, and we're not just working on the empeg-car here - we have other things to do too.

Better bug reporting may help us: if the volume is going up, does pressing and releasing the volume up button stop it? Does pressing and releasing volume down help? Do any buttons work? Does the remote work in this circumstance? Anything special, eg track border, middle of track, etc.

Hugo