Bugzilla – Bug 2018
Player Remote Keys sometimes bounce
Last modified: 2008-12-18 11:38:58 UTC
When browsing album/artist/playlist/etc menus using the player remote, pressing the up and down arrow keys (in particular) sometimes moves the menu on by two steps rather than the one intended. This happens even with short key presses. I have also observed similar behaviour when using the number keys to enter (network) settings into the player. It seems like a key debounce issue. It maybe that it only occurs in the above situations because either the slimserver application responds very quickly, or is not required to respond at all. It seems to occur in all Firmware versions although I'm currently using svn 4033/V16 on ubuntu. see: http://forums.slimdevices.com/showthread.php?t=14609 for other comments.
What kind of remote are you seeing this with? I can't reproduce with my Slim Devices remote.
With the supplied Slim Devices remote. I probably see it ~5% of the time I use the up and down keys in browse menu.
I use quite a low spec server - is server response time a factor?
Probably not the CPU speed, the button presses are timestamped by the player. One thing is that as one presses the button, more than one IR event may be sent. We've got some carefully tuned timing in there to ignore multiple events if they come close enough to one another (and other parameters that detect if you are pressing and holding). if one or more IR signals are dropped (due to interference with florescent lights, other IR signals, etc) a single press may appear as two presses, depending on how long you hold the button down. So, do you have fluorescent lighting in this room? Low batteries in the remote? Other sources of IR that could interfere?
"So, do you have fluorescent lighting in this room?" No - none in the house at all. "Low batteries in the remote?" No - don't think so. "Other sources of IR that could interfere?" Not that I can think of. I just posted on the thread - are we only seeing this in the UK I wonder? Although I can't for the life of me think how that would work ...
Dean, I see this too. I've not tested enough but think it occurs most on one of my 3 remotes (the newest one). I think it comes from switch bounce as if you softly press a button and slowly release it occurs - i.e. the release is generating bounce. Could you describe what debounce is in the player and what is in the server and then maybe I can help debug... Is the bebouce in SB1 the same as in SB2 - I've only noticed on SB2, but then I've not tried different remotes carefully with different players (yet)
triode: can you confirm that it happens only with one of your remotes? If so, I'd gladly trade you for one that doesn't so I can inspect the bugger.
I certainly have a reproducable case here too. I havne't tried using the same remote with other players, so it might be a specific set, or just the remote.
I have a feeling it's environment rather than remote specific. I took my SB2 to someone else's house and tried it there and I don't recall any problems. We did have two remotes though, and I can be 100% sure I was always using mine. I will try here with both my remotes and report back.
OK, it happens with both my remotes, in my room. The second remote is brand new, never been used before, batteries freshly removed from the sellophane. The room has no other IR transmitters in it at all. Lights are all incandesent types (off at the moment). It does have a lot of glass though - one 5.5m wall is mostly floor to ceiling oak framed windows. The SB2 is on the opposite side of the room (4.75m wide), screen facing the glass windows.
I did swap remotes round and was able to reproduce with the other remote so I it is not simply the remote. I think Patrick may be onto something with reflections - I have a plain light coloured wall on the opposite side of the room to the SB2 causing problems. I also often reflect the remote off the wall [works for my CD player etc]. Perhaps we need to do some tests with large black sheets over the reflective walls... Dean - is the timing done in the firmware or the server. I would expect a minimum off period to be defined before a new press is registered - but I didn't find that in the server on simplistic examination.
I am fairly certain this is a recent thing too. It happens a lot on my upstairs player, but I dont recall it being a real problem prior to fw18 or 19. Scrolling a short menu seems to go so fast that the display almost sticks to one item and flickers. There was a time when this was not the case. Perhaps it could be due to the increasing efficiency of the display code highlighting an exisitng problem. Hard to say from this end.
kdf's comment about firmware versions may be relevant too - when I took my SB2 to my friend's house (see above), he was running on 6.01 and so the firmware got downgraded. Maybe that's why I didn't see it there?
well, I updated svn when I got home. I forgot to test, but tried after doing the update to fw21. My reliable case was the menu in the alarm clock. Now, I can't reproduce. The items scroll as I would have expected. I'll leave the server on for a while and try later to see if its a time thing.
I've updated to svn4227 and the fw update, and I'm still seeing it.
I would love to see d_ir output while this is happening. Anybody able to reproduce?
Here you go - 5 'downs', the last one jumped down twice. Menu is the playlist. HTH 2005-09-15 20:46:37.0266 7689b04f 468704.015 1126813597.02634 2005-09-15 20:46:37.0308 found button arrow_down for 7689b04f 2005-09-15 20:46:37.0325 found function down for button arrow_down in mode common from map Default.map 2005-09-15 20:46:37.0339 irCode = [down] timer = [468704.015] timediff = [119.758000000031] last = [up_repeat] 2005-09-15 20:46:37.0350 irCode: down, 00:04:20:05:aa:33 2005-09-15 20:46:37.0370 irCode not defined: down 2005-09-15 20:46:37.0379 trying to execute button: down 2005-09-15 20:46:37.0418 executing button: down 2005-09-15 20:46:37.1437 7689b04f 468704.132 1126813597.14345 2005-09-15 20:46:37.1454 found button arrow_down for 7689b04f 2005-09-15 20:46:37.1470 found function down_repeat for button arrow_down.repeat in mode common from map Default.map 2005-09-15 20:46:37.1486 irCode = [down_repeat] timer = [468704.132] timediff = [0.116999999969266] last = [down] 2005-09-15 20:46:37.1496 irCode: down_repeat, 00:04:20:05:aa:33 2005-09-15 20:46:37.1515 irCode not defined: down_repeat 2005-09-15 20:46:37.1525 trying to execute button: down_repeat 2005-09-15 20:46:37.1552 executing button: down_repeat 2005-09-15 20:46:37.5435 found button arrow_down for 7689b04f 2005-09-15 20:46:37.5452 irCode not defined: arrow_down.single 2005-09-15 20:46:38.2323 7689b04f 468705.221 1126813598.23148 2005-09-15 20:46:38.2361 found button arrow_down for 7689b04f 2005-09-15 20:46:38.2376 found function down for button arrow_down in mode common from map Default.map 2005-09-15 20:46:38.2389 irCode = [down] timer = [468705.221] timediff = [1.08900000003632] last = [down_repeat] 2005-09-15 20:46:38.2398 irCode: down, 00:04:20:05:aa:33 2005-09-15 20:46:38.2419 irCode not defined: down 2005-09-15 20:46:38.2428 trying to execute button: down 2005-09-15 20:46:38.2453 executing button: down 2005-09-15 20:46:38.3691 7689b04f 468705.358 1126813598.36888 2005-09-15 20:46:38.3710 found button arrow_down for 7689b04f 2005-09-15 20:46:38.3725 found function down_repeat for button arrow_down.repeat in mode common from map Default.map 2005-09-15 20:46:38.3740 irCode = [down_repeat] timer = [468705.358] timediff = [0.136999999987893] last = [down] 2005-09-15 20:46:38.3751 irCode: down_repeat, 00:04:20:05:aa:33 2005-09-15 20:46:38.3772 irCode not defined: down_repeat 2005-09-15 20:46:38.3783 trying to execute button: down_repeat 2005-09-15 20:46:38.3813 executing button: down_repeat 2005-09-15 20:46:38.7493 found button arrow_down for 7689b04f 2005-09-15 20:46:38.7508 irCode not defined: arrow_down.single 2005-09-15 20:46:39.5197 7689b04f 468706.509 1126813599.51943 2005-09-15 20:46:39.5228 found button arrow_down for 7689b04f 2005-09-15 20:46:39.5244 found function down for button arrow_down in mode common from map Default.map 2005-09-15 20:46:39.5259 irCode = [down] timer = [468706.509] timediff = [1.15100000001257] last = [down_repeat] 2005-09-15 20:46:39.5269 irCode: down, 00:04:20:05:aa:33 2005-09-15 20:46:39.5291 irCode not defined: down 2005-09-15 20:46:39.5301 trying to execute button: down 2005-09-15 20:46:39.5327 executing button: down 2005-09-15 20:46:39.6561 7689b04f 468706.645 1126813599.65586 2005-09-15 20:46:39.6579 found button arrow_down for 7689b04f 2005-09-15 20:46:39.6596 found function down_repeat for button arrow_down.repeat in mode common from map Default.map 2005-09-15 20:46:39.6611 irCode = [down_repeat] timer = [468706.645] timediff = [0.135999999998603] last = [down] 2005-09-15 20:46:39.6622 irCode: down_repeat, 00:04:20:05:aa:33 2005-09-15 20:46:39.6646 irCode not defined: down_repeat 2005-09-15 20:46:39.6659 trying to execute button: down_repeat 2005-09-15 20:46:39.6689 executing button: down_repeat 2005-09-15 20:46:40.0380 found button arrow_down for 7689b04f 2005-09-15 20:46:40.0397 irCode not defined: arrow_down.single
Patrick, I only see three presses in that log, there are two others that happen 0.13 seconds after, which is likely a repeat code from the remote. My theory about what's happening is that you are holding down the button long enough to send enough repeat codes to make the software think that you are holding it down and want to accelerate through the list. Try pressing very lightly and quickly and see if the extra skips go away. Once we understand exactly what's going on we can fix it correctly.
Believe me, I am only pressing lightly! Surely the software should not see/generate repeat key presses 0.13 seconds after the original press? I admit I do have reactions slightly sharper than Michael Schumacher, but even I can't just hold the key down for less than 0.13 seconds!
Even a very light press may generate a repeat code, and that's expected. We do have some complicated heuristics to drop repeats, except after you continue to hold it down for some length of time (currently about a half a second) wherein we trigger a "hold" and then start repeating. The strange thing in the log is that the ir signals come in with time stamps of .12, 1.09, .14, 1.5, .14 seconds apart. I'm assuming that you were pressing lightly and about a second apart, which means that we saw only three of your presses each of which had an expected repeat code right after. Was there more output that we missed? If you feel like experimenting with the timings, feel free to look in server/Slim/Hardware/IR.pm at the values for IRMINTIME and IRSINGLETIME and try increasing them a little bit.
I'm pretty sure that was all the output. I enabled d_ir, checked the log (empty), walked to the SB2 (in another room), pressed the down arrow key 5 times (at which point I got the first double jump), and then stopped and cut and pasted the log output. I wouldn't always see the double key action as quickly as that, but I can reproduce it pretty easily. Is it possible that it's not detecting the 'unpress' correctly? It should have just been 5 single presses and no repeats at all. I'll happily play with the settings and report back. If there are any specific numbers I should try, please let me know.
OK, I have tried IRMINTIME = 256 IRSINGLETIME = 512 and it seems to work well for me - repeat seems fine too. It would be good if someone else tries these settings too. Triode, are you there? If these numbers need to be honed, I can try others - but this looks like it's the right track. Thanks Dean!
OK - I'll try these (possibly tomorrow though)..
I've just tried Patrick's suggested settings and it seems to be working well, I've not seen a single bounce since changing teh settings, will report back if anything further spotted. Looking good though!
Just tried Patrick's values - these do seem to prevent the double scroll, but come at the expense of not being able to move rapidly thought the list by repeated presses of the key. [This is very noticable with softsqueeze where you can repeat a key click very rapidly with a mouse... but is also noticable with a real SB2 - to the extent that I think they are too long] Dean, seems to me that we can tinker with this value, but perhaps there should be two different cases we are trying to trap (which may mean more significant changes): 1) User wants to repeat a button press by holding it down - in this case the timer should be quite long and we consider the key still pressed if we only have short interuptions during this time (to cater for bounce and whatever the IR equivalent is) 2) User wants to move rapidly though a list - in this case as long as they take their finger off the button for a defined period we should consider it a new press. I don't quite understand what is going on in the firmware at present - could you explain what causes it to generate an IR frame.
I think a common way to do it, is to require the key be held down for a longish period to get into repeat; and then a shorter period once in repeat, to continue repeating. I probably don't notice the slow repeat, because my server responds very slowly - so I'm not best placed to test that aspect. The values I suggested were my first attempt, so there are probably more optimal ones!
The server is just sending individual messages, with timestamps, for each IR packet received. So all the clever behavior is on the server side. I think that triode is probably right, we'll need a bit more logic here to fix this problem, rather than just tweaking timing values. The existing code, while convoluted, is pretty well tested, so I'm hesitant to make any changes without a substantial opportunity to test. And, of course, patches welcome.
Having looked a bit more at the code, I think we could probably solve this by increasing $holdTimeBeforeScroll in Slim/Buttons/Common.pm This only changes the length of time the up/down buttons must be pressed in a scrolling list to start repeat scrolling. It does not impact rapid key presses to move through the list. At present it is 0.300 (300ms). IR repeat codes are produced by the player at ~108 ms intervals [SB2 seems to have jitter on this - sometimes it is <90ms, then >125ms]. This means that repeat codes are received at (from SB1): Scroll Holdtime: 0 Scroll Holdtime: 0.108000000000004 Scroll Holdtime: 0.216000000000008 Scroll Holdtime: 0.324000000000012 Scroll Holdtime: 0.432000000000016 Hence the default value of 300 only screens out the first 2 repeats. To screen out more we need to set it to a larger value. I recommend $holdTimeBeforeScroll = 0.350 or 0.450 Please try and let me know what you think. I suspect SB1 and SB2 potentially suffer the same problem if you hold down the keys for too long, but the animation on SB2 makes it more noticable and the extra jitter between IR updates on SB2 makes it more likely to get a fourth IR frame for a single key press.
Dean, I note there is code in IR.pm to check for a missing repeat code - is this one that is missed by the player or the server? For SB2 I have shown that the timestamps on repeat codes have significant jitter and hence this bit code won't work as it only allows 2% jitter - is this relavent in this case?
Created attachment 883 [details] IR Repeat debug Here's some more debug which shows the jitter on IR timestamps produced by SB2 compared to SB1. Specifically when SB2 is busy the repeat codes appear to be delayed. In the example, if keys are pressed on an SB2 which has just started to play a new file (FLAC) and has a visualiser running, the repeat code extends out beyond IRMINTIME and is considered a new key press. I also think there is one case of a missed repeat code which is not detected due the the jitter on the repeat code stamps (see previous post). Is there anything that could be done the the firmware to make the timestamps more accurate like SB1? If not I think IRMINTIME needs to be bigger - say 0.165 and we need to think about the missed code case. Attachment shows debug code added and outputs for SBG and SB2.
It would be possible to get much more accurate time stamps with some re-working of the IR mechanism. SB2 measures the pulse widths at interrupt time, but the time stamps sent to the server are sampled in the application context, which has higher latency. I'll look into it further...
Here's a question, Patrick, what format audio are you playing when you see the bounces?
My library is 100% FLAC. Accept No Substitutes. (When you absolutely have to kill every motherf*cker in the room)
I'm sure there's a really good reason, but why not do the key debounce in firmware and just send debounced commands up the ether?
It's not a traditional "debounce" which deals with intermittent contacts , rather we need to use the IR packets and their timing to decide if somebody has: pressed and held, pressed and released, pressed and released twice, etc... In addition, the context matters, in the case where we don't do anything on a press-and-hold we can respond more quickly (i.e. not wait and see if they've held down long enough) etc.. Given that IR is not completely reliable, we need to take loss of packets into account. It's complicated and as we've seen having accurate time stamps are important. Sean's going to improve the accuracy in the firmware.
sean's not going to make it for 6.2, but he should have time next week.
Not going to make it for 6.2.1
Previously reported as bug 1391: https://bugs-archive.lyrion.org/show_bug.cgi?id=1391 I've had this problem for ages, glad someone else can finally reproduce it :) You learn to compensate for it, but if it gets fixed, all the better. It happens even when I'm pointing the remote directly at the SB from a distance of 2m, in all conditions of lighting. Scrolling through 'Browse Artists' with nothing yet playing is enough to trigger it.
Try altering some of the timings per message #20 above. I've done this with some success, although it does tend to limit how rapidly you can press the buttons. For me this is less of a problem than the key repeating when it shouldn't. Andy. (In reply to comment #38) > Previously reported as bug 1391: > > https://bugs-archive.lyrion.org/show_bug.cgi?id=1391 > > I've had this problem for ages, glad someone else can finally reproduce it :) > You learn to compensate for it, but if it gets fixed, all the better. > > It happens even when I'm pointing the remote directly at the SB from a distance > of 2m, in all conditions of lighting. Scrolling through 'Browse Artists' with > nothing yet playing is enough to trigger it. >
I have a patch and will be testing it shortly.
Please try tonight's nightly build and firmware 35. Time stamps should be much more accurate (they are captured at the time of the IR signal, not when the packet is sent). Reopen with details if you are still seeing issues.
Is the patch for 6.2.2 or 6.5, or both? I have updated to the latest 6.2.2 nightly but the firmware has only updated to vs. 63. I'd dearly like to see the back of this problem but would prefer not have to update to 6.5 as I fear new bugs may be introduced to my system.
(In reply to comment #42) > Is the patch for 6.2.2 or 6.5, or both? > I have updated to the latest 6.2.2 nightly but the firmware has only updated to > vs. 63. > I'd dearly like to see the back of this problem but would prefer not have to > update to 6.5 as I fear new bugs may be introduced to my system. > I have exactly the same question.
6.2.2 includes it but you need the 22-1 nightly, I think the latest nightly (rpm) showing was 21-1 up to a few minutes ago, so check which nightly you have actually downloaded. The version number should be 6.2.2 - 6337 etc By the way, first impressions are good ... Thanks.
FYI. Since the 2/21 fix, I've never experienced a single bounce, and it used to happen every other remote press for me. Thanks!
I have to agree. It seems to be sorted. Thank you very much you wonderful people.