Add remote repeat filter settings tweaks to MyOSMC

Feature Requests
1

I know you are actively looking at how to handle the repeating on remote keys, and after playing around a bit, I don’t think there will ever be a “one size fits all” solution.

With the current eventlircd startup using --repeat-filter to enable time-based repeat filtering, sometimes buttons that auto-repeat (like the arrows) will repeat on Kodi, and sometimes they don’t. Mostly, auto-repeat fails if the key is held down for a while and repeat works, then the key is released and pressed again without another key intervening. And, when repeating did work, it took quite a while to start, then moved at a reasonable speed for a while, then accelerated to way too fast.

On the other hand, I tried removing the --repeat-filter option to disable time-based repeat and enable the default count-based filtering, repeats worked more reliably, but also were much too fast, like the end stages of the time-based repeat. But, I couldn’t figure out whether the osmc user was the correct place to try to tweak the .lircrc file.

Now, I’m sure people with other remotes (like CEC, or the OSMC remote, or Harmony) will have different experiences, because no remote sends exactly the same way. What this tells me is that we need something the user can easily configure (no ssh required) to set the delay for first repeat and max repeat speed parameters, and maybe a “ramp-up” value that says how fast the repeat speed increases (if at all).

Putting this in MyOSMC will allow the config to be set and some kind of dummy list used to allow the user to test the settings without having to go back and find an appropriately long list somewhere else in the interface. Since MyOSMC is part of the Kodi user interface, the demo test should be fairly realistic compared to actual Kodi screens.

2

At the moment our parameters are hard coded at build time.

They could be extracted out, but it’d be good to see if there was a benefit from this first

3

To expand on this, the repeat filter is set here:

Changes were made by @dbmandrake in the above commit to provide a better experience.

Sam

4

OK, based on my reading of the code, either version will “kill” the repeat (setting device->current.repeat_count to zero and ignoring the button press) if the first repeat isn’t within a certain period of time. The old code was 0.9 seconds, and the new is 0.25 seconds. As the repeat count gets higher, the time for a kill gets lower. The only difference in the code is the “slope” of the kill curve.

It’s odd that both sets of code include more than one kill time after the first repeat, as almost every device has a longer delay between first and second send of a key (the second send is the first repeat, but is checked in the code by repeat_count at zero, since it’s looking at the first send for the count), but then a constant (and usually lower) delay after that.

But, any remote that is far faster at repeat rate than the first number will never repeat at all…holding down the button will result in no repeats ever. For devices that do pass that first threshold, the old code limited the repeat rate to 2/sec for most devices, while the new code should limit to about 5.5/sec (the 28/sec should never be hit, as any device that jumps to 28/sec will be throttled to 5.5/sec).

I don’t see how the code explains what I see, though (unreliable start of repeat, but when it does start, it ends up being far faster than the 5.5 repeats per second limit that should be). But, any remote that has a repeat rate that is close to any of the threshold numbers will result in unreliable repeat, and maybe that’s what I’m seeing. But, it might also be a hardware/driver issue at a lower level. All of the code in input_device_event_update assumes that the event has been successfully parsed into press (1), repeat (2), or release (0) by lower level code.

So, assuming the code in input_device_event_update is getting good data from the hardware and driver, it’s obvious that repeat throttling needs to be controlled by numbers stored in a config file that is accessed at runtime. This makes tweaking to find the right numbers for an individual remote much easier.

Another thing that would help would be having a config in the same file that controlled a debug output (not Kodi debug, but maybe to /var/log/lircd) that showed the key event with the raw time (down to the microsecond). This would allow the user to find out the actual repeat rate of their remote, to help in tweaking, and check to see if there is something like a hardware issue (IR receiver not seeing all the repeats), or other kernel code that is affecting the input timings.

5

Sorry for the delay in getting back to you.
Which LIRC profile are you using?

Agree – and maybe our sane defaults need revisiting.
Do we want something similar to CEC repeat input filter?

How do we limit the ability of a user to break their remote (and lock themselves out) by setting dumb values? A revert after 60 seconds option?

Sam

6

I’m using a slightly modified version of the Hauppage PVR-350, which is an MCE remote. It turns out this is a large part of the problem, in that although sometimes I get repeat when holding down a key, it should never happen, as this remote doesn’t send repeated _DOWN…every _DOWN is followed by an _UP about 0.25 seconds later, regardless of how long (or short) I press the button. I have no idea how I can sometime get a press-and-hold to scroll down a list with this remote. I’m now trying to find a remote that I can start from that has enough keys and sends repeats and doesn’t conflict with my other devices.

Keyboards and remotes that I have that auto-repeat tend to send the first _DOWN, then wait for 100 units (an arbitrary value as an example), then send the second _DOWN, then repeatedly wait for 20 units, send a _DOWN, etc. Even if a remote does speed up a lot more than that, people are used to this sort of a setup, with a longer delay before the first repeat, then a constant delay for each one after that. So, the code really only needs two values, not the 3 (or 6 that the old code had). This will also make a UI easier (just two input fields).

One way to keep the user from breaking the remote is to set a hard limit for how low each number can go, with the first repeat around 0.15 seconds, which is still lower than almost every keyboard can be set for the delay on first repeat. But, it should be good enough that they can navigate back, although carefully.

Another way would be to have a test list screen that is invoked after the “OK” on the numbers. The user can use up and down arrows (and PageUp and PageDown) to test. Once they hit Esc/Back, then the repeat rate is set to the default, and another dialog asks if they are sure, with “No” being the default. Only if they answer “Yes” are the new numbers saved and applied.

Also, there should be a “benchmark my remote” screen, where you ask the user to press a button that they expect to auto-repeat (like down arrow) for 5-10 seconds, and then read what you get with no repeat filter, and display the first repeat delay and the max repeats per second. This would let the user know the that they can’t get for 100 repeats/second if the remote only sends 25. It would also have told me “hey, dummy, your remote doesn’t repeat at all”. :disappointed:

Default max repeats per second shouldn’t be much more than 20, since that’s about where most devices seem to be these days. Default to first repeat should be no less than 0.25 seconds (like it is now), and maybe even a bit higher. If there is a UI to make repeat faster, then people that want/need it will, while others won’t complain about constantly overshooting.