Rockbox

Just to note, this bug has been present for *months*. As best I can tell it was created with the fix that kept scroll events from stacking up. So, now you can't accidentally scroll too far and adjust the volume all the way up to +6 because it's a bit laggy, but you get this instead. :)

I have a Nano with the same bug... I know it's not exactly severe, but it's extremely annoying.
Hopefully this will become fixed some point soon ^_^

This bug is also present on my nano, it's pretty annoying.. I hope someone will look into this.

Could somebody with an iPod please do a quick check with a current build and report back on whether this bug is still present?

Yup, the bug's still present on the current build (as of this post, anyways).

I can reconfirm this bug still exists (iPod Video 60 Gig) r18335 clean install (and earlier r18205)
Easily reproducible in file (tree) browser.

Possibly related problem.

Plug-ins that require you to use the hold to get to the menu frequently show same symptoms (“Whenever the HOLD switch is turned off, the hold icon in rockbox disappears, but hold actually doesn't let go.”) but scrolling doesn’t fix it. Controls are unresponsive. Sometimes after using the hold again or pressing random buttons it will resume function, other times I have to reset (select + menu). It doesn’t always happen but happens a lot in RockBoy especially when you go back and forth to the menu and use a buggy game from PDroms. I've also noticed it in RockDoom r18205 after I've been playing a while.

Good luck with Version 3.0 Thanks everyone for the wonderful firmware.

I would like to reconfirm that this bug is present in sansa e200 series DAPs as well...

Problem still present on both iPod 5.5G and 4G photo with current build

In reference to Eliot using the hold button to access the menu in rockboy is extremely unreliable and often takes more than 10 tries to successfully open the menu

This is very easy to reproduce in the file browser on my 5G 30GB iPod. It happens almost half the time.

What I see is a problem in button-clickwheel.c. Interrupts are occurring, but (status & 0x800000ff) != 0x8000001a. I found this by commenting out the backlight_on() statements in button.c and button-clickwheel.c and strategically adding new backlight_on() statements.

Here's a patch which seems to fix the problem on my 5G 30GB iPod. It should also be test be tested on 4G and Nano iPods.

To reproduce the problem with SVN: In the file browser, turn hold hold on and then off. Press the centre (select) button without touching the wheel. About half the time, the first few presses are ignored.
With this patch, I am unable to reproduce the problem.

BTW. When this problem happens, values read from 0x7000c140 seem like garbage with many 0x55, 0xAA, 0x00 and 0xFF bytes.

For iPod 5G (60GB), I confirmed the firmware that applyed the patch worked well.

But iPod Photo does not work.
iPod Photo did not work though the my patch in  FS#10098  was applyed.

For iPod Photo:
HOLD on
0x7000c100: 600a1f00
0x7000c104: 41000000
0x7000c140: 00000000

HOLD off
0x7000c100: 600a1f00
0x7000c104: 61001e00
0x7000c140: 55555555, aaaaaaaa, ffffffff (etc)

Does this patch fix the problem on iPod Photo?

I don't like putting udelay(2000) in an interrupt handler. Any comments on that?

When the new patch was used, iPod Photo and iPod 5G worked fine. thanks!!

I had some problems with ipod_4g_button_int-variant2.patch on my 5G iPod. Sometimes the clickwheel or buttons didn't respond until I pressed a different button or scrolled in the opposite direction. Here's an updated patch which doesn't seem to have those problems.

iPod Photo works fine when new patch applied.

But for iPod 5G, the following problem found.

The HOLD switch is turned on, and the screen fades out.
After it waits for a while, the HOLD switch is turned off.
Then, the HOLD icon is sometimes displayed on the screen.

For original Rockbox firmware (r20674), r20674 + ipod_4g_button_int-variant2.patch such the problem did not occur.

When the HOLD icon is displayed after the hold switch is turned off, do buttons and the wheel work? If they work, I think this is due to an issue with  FS#9890  (5G iPod LCD sleep): if lcd_update() is called while the LCD is being initialized, that update will be ignored. The fix is in bcm_lcd_wakeup_improved.patch there. Alternatively, you can disable LCD sleep via LCD options and see if the problem still occurs.

When iPod 5G worked fine by using
r20684+ipod_4g_button_int-variant2_v2.patch+ bcm_lcd_wakeup_improved.patch, the display is normal.
Both iPod Photo and iPod5G works fine.
thanks!!

P.S.
bcm_lcd_wakeup_improved.patch cannot be applyed to the source of the latest version. You should update it according to the source of the latest version.

I had the same problem with the hold icon, but the fix for  FS#9890  has corrected it.

Is this awaiting more testing? What players does it still need to be tested on? It definitely fixes my 5.5G :)

I don't think anyone has tested this on Nano or Mini 1G.

I'm also wondering if it is okay to have udelay(2000) in an interrupt handler. I am hoping it is okay because it doesn't run often. It is only in the code path which is executed when this problem occurs, not in the normal code path which successfully reports key and wheel events.

very simple fix.. linuxstb pointed out that the ipodlinux code reenables the opto when hold is disabled.. so added that and it seems to work :)

The trivial patch posted by jdgordon also fixes the issue for my 5.5G, as far as i can tell (I did remove the other patch first).

I can also confirm that the new one-change patch works for me on my 5G iPod.

It looks like the fix which was committed hasn't actually fixed the problem for Mini 2G and possibly other models, see http://forums.rockbox.org/index.php?topic=23997

I also have this problem on my 5.5G ipod with rb 3.5. The ipod remains unresponsive until about 6 clicks of a button or scrolling is performed. If scrolling is the first action performed, then there is a ~0.5-1 second delay.

I don't have my 3G ipod with me right now, but I do recall a similar issue with that one as well. I couldn't rewind a track in the WPS after releasing hold unless I waited a couple of seconds before holding the rewind button. If I was too speedy and pressed the button right away, and then continued to hold down the button, then released for only a short period of time, a second or third, or fourth attempt like this would fail. I also remember occasionally not being able to scroll until tapping the center button first, but that may not have been associated with the hold switch.

oops! I meant to say that I'm using rb 3.6 on both the 5.5G and 3G ipods.

I tried the current build (r28207) and am still having this problem. If it helps, my 5.5G is hw rev. 0x000B0011. I think that the issue I described about the 3G ipod above is different in nature from this bug.

using ipod_4g_button_int-variant2-v2.patch on rockbox 3.6 fixed the issue for my 5.5G ipod. I manually copied in the code, because the patch was originally for an older version of rb.

I don't know that we want to commit that patch, unfortunately; it sleeps in an interrupt handler which is a bad idea...

It's odd that only one person would report having the problem...

Who knows why I was having this problem. I bought this ipod from someone on amazon. It looks like it's been opened, so maybe it's been refurbished. *shrug*

I'm not the only one who found a variant of "ipod_4g_button_int-variant2-v2.patch" useful. mg0rb did as well. His post is here in the forums: http://forums.rockbox.org/index.php?topic=23997.0

should I try a version of the ipod_4g_button_int-variant2-v2.patch without udelay?

You could, but the udelay is probably what's making it work properly.

We know that that patch helped the button problem, what I meant is that you are the only person having that problem on ipodvideo; several people have reported it's not fixed on mini and it's expected that the other patch will work there, but you are the only person with any *other* model having an issue. The video is the most common ipod for rockbox and a lot of the developers have one, so it's rare that only one person reports a problem on it; some of the other models are rarely used and it's more likely there :)

I believe I observe a variant of this bug with Rockbox 3.7 on an ipod nano 2g. Keys stay locked unless I press select first.

I would like to confess that this bug is still present with new RB 3.7.1 at my Ipod nano 1gb 1 gen.

100% times after HOLD button is used buttons (prev, next, play/pause, select) didn't respond for 2-6 clicks and after it works just fine.
If after unlock scrolling is used then all buttons respond normally. I can reproduce it any menu, directory list or WPS.

"I believe I observe a variant of this bug with Rockbox 3.7 on an ipod nano 2g. Keys stay locked unless I press select first."
This definitely didn't work for me.

I'm using Ubuntu and fail to install proper software to compile source code with ipodfix.diff.
.sh script getting stocked while installing GCC. Anyway if this possible i would like to ask some advanced rockbox user to send me proper version RB with this patch (no? ok :). Or wait couple weeks and i'll try to get it work at my PC.

P.S. Anyway i feel such a relieve not using iTunes. Thank you for all that work!

I'm not sure if anyone is still watching this, but I was unable to reproduce this bug on both iPod Nano 1g and Sansa e200 simulator builds of r29827-110507.

You wouldn't be able to reproduce this on simulator builds; the problem is with the device driver that talks to the clickwheel, which doesn't exist on the sim.

I uploaded 3.8.1 stable release today to my Ipod Nano 1g to test it and problem is still here. But good news is that I'm so used to it now so it's starts looking like feature :)

P.S. I installed GCC in January (take a look at my last post. Thx again Torne!) but it looks like .diff files that placed at this topic can't be automagically applied to source..

I am also seeing this issue on an iPod 5G (iPod Video 30GB). After hold is turned off, next/previous/menu/select/play don't respond for 5-6 presses. Using the scroll wheel or pressing any button multiple times will fix it. I have tried with Rockbox 3.9 and r30324 - no difference.

With my Ipod nano 1st generation i tried version 3.9.1 today and the bug is still here.
Also compiled source code from revision 21912 with Jonathan's Gordon "ipodfix.diff" (thank you Jonathan!) but for me nothing actually changed.

This is still a problem with my ipod 5.5G. The ipod_4g_button_int-variant2-v2.patch worked for all the releases I've tried, except for 3.9.1.
Maxime, the ipodfix.diff is already incorporated in the code.

Still a problem with my mini2G with latest dev build