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):
- Reboot Ropieee if running
- Start playing something and run
- Pause playback with play/pause key. See
a4 0 KEY_PLAYPAUSE /dev/input/event1record in
irwoutput, which is normal
- Wait at least 36 minutes.
- Try to press play/pause again. See that playback is not resumed and
a4 1 KEY_PLAYPAUSE /dev/input/event1record appeared in
irwoutput. Value 1 for counter is not correct without previous 0.
- Press play/pause again. Playback is resumed and correct record appeared in
- 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
My workaround is provide minimal integer value for
-r parameter in
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.