Flirc integration bug - error in inputlircd

Audio Gear Talk RoPieee
1

Hi, I found annoying bug in Flirc integration for Ropieee and want to report it to @spockfish:
Steps to reproduce (required Flirc receiver and IR remote with KEY_PLAYPAUSE mapped):

  1. Reboot Ropieee if running
  2. Start playing something and run irw in SSH
  3. Pause playback with play/pause key. See a4 0 KEY_PLAYPAUSE /dev/input/event1 record in irw output, which is normal
  4. Wait at least 36 minutes.
  5. Try to press play/pause again. See that playback is not resumed and a4 1 KEY_PLAYPAUSE /dev/input/event1 record appeared in irw output. Value 1 for counter is not correct without previous 0.
  6. Press play/pause again. Playback is resumed and correct record appeared in irw again
  7. Wait another 36 minutes and this all repeats again

The cause of this bug in inputlircd daemon which handles USB HID input events. Its source code has time_elapsed function which calculates time between clicks in microseconds and stores it in long variable. But looks like program is compiled with 32 bit long which overflows every 35 minutes and becomes negative. Program logic doesn’t handle this and produces repeat value without initial zero, which is not catched by irexec
My workaround is provide minimal integer value for -r parameter in /etc/default/inputlirc. As inputlircd multiplies it by 1000 this value is -2147483. This looks to be working in most cases. I’m not sure what is best fix for Ropieee, may be use lircd which has more sophisticated logic for repeat detection and probably free from bug.

2

I see that issue is fixed in Ropieee NG and it is using completely different program to read Flirc events.

3

yes it does.