Bugzilla – Bug 7926
Front Panel button modifier problem
Last modified: 2009-07-14 07:07:14 UTC
The front panel/snooze buttons seem very prone to accidental .hold modifiers. This is likely an issue in the timers that convert .down and .up into the standard button modifiers.
With Triode's Power/Home button patch in forum, http://forums.slimdevices.com/showpost.php?p=293236&postcount=17 this problem also seems to apply to the Power button.
Related to #7891?
possible, but then a double push should mean that the .hold won't happen. If they are indeed the same source problem, it could get ugly.
Or is the double push actually a repeat? I'm out of my depth here. ;-)
If I can ever get time away from home modification, I plan to have a look at the player.ir information. Last time I dug into that part of the code, it was a very long process.
Anyone who does end up with time, turn on player.ir for debug and look for mention of "Front panel button". The log should show press events and release times. Also of interest may be the "Hold Time Expired..." messages
Created attachment 3346 [details] Four snooze button single presses I pressed and released the snooze button four times. Button was released after 0.15 and 0.22 seconds according to SC log. Even though this were single presses, on the fourth press, SC also executed the .hold function. Seems like the hold timer doesn't get canceled upon a button release?
Forgot to mention: Boom fw 7 and SC r 19699
how about this: ndex: Hardware/IR.pm =================================================================== --- Hardware/IR.pm (revision 19712) +++ Hardware/IR.pm (working copy) @@ -760,6 +760,9 @@ if ($dir eq 'down') { $log->info("IR: Front panel button press: $code"); + + # kill any previous hold timers + Slim::Utils::Timers::killTimers($client, \&fireHold); my $irCode = lookupFunction($client,$code);
Created attachment 3347 [details] kill hold timer we need to kill on press AND release.
Looks good to me. Tested with snooze button and I don't see accidentally .hold events anymore. Could you commit your patch please, thanks.
I put this into 7.1 at change 19731, as this is applicable to transporter as well.
This bug has been fixed in the latest release of SqueezeNetwork! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.