Rockbox General > Rockbox General Discussion

Am I the only one having problems?

<< < (5/5)

jorj:
Turning keyclick off did not appear to help. But some other testing was interesting...

1) Played a playlist in RB until it started going insane.
1a) Locked the buttons out while going insane.
2) Played for 18 Hours until I shut it down - no problems.

Conclusion:
  Must be a hardware problem with the buttons pressing themselves.

3) Played the same playlist in OF with the lock button in the unlocked position to see this hardware error happen there. played all night and all day while at work
Was STILL playing when I got home. I have listened to it for several hours with no adverse effects.

Conclusion:
  Previous conclusion was wrong.

Guess:
  Perhaps the OF handles the debounce of keys differently. Mabey this phantom keypress is normal for this model and the OF can spot the difference.

Final Conclusion:
  I now know how to get RB to play my songs and playlists. Even though it is cumbersome to have to remember to unlock it each time I want to make a change in the somg selection, skip a song, adjust the volume, It is not a severe enough problem to make me go back to the OF full time. The only REAL problem now is that if the phantom keystrokes happen to be hitting when I unlock it -- who knows what it will select or what menu options it will change? Anyway, I'll live with it this way until a change is implemented that squashes this bug. Dang! Looked like it really was a hardware problem, but a hardware problem that only exists under a single firmware makes the firmware at least a little guilty.  Like microsofts java bug, many of the other browsers had to impliment the "bug" to be compatible..

-- Preciate the quick and usefull responses I received here. Great forum. When things slow down for me a little - might download the source and see if I can track this thing down on a more technical level. Assume it is written in C, C++, or another language that I already know? - Later

yapper:

--- Quote from: jorj on April 25, 2008, 07:15:27 PM ---might download the source and see if I can track this thing down on a more technical level. Assume it is written in C, C++, or another language that I already know?
--- End quote ---
If you do decide to take the plunge, you might start looking at button-1g-3g.c (at firmware\target\arm\ipod within the source). In particular there is a delay that was tweaked from 250 down to 50 compared with the ipodlinux code, which appeared to be fine (presumably on 'good' hardware) but this might be making it more prone to the issue you describe. The original value of 250 was described as causing the wheel to stop working when spinning it real fast, so the optimal might be < 250 and > 50.

Navigation

[0] Message Index

[*] Previous page