3.27.15+
FW Version: v4.10.5
   SKU:     Flirc 2.0 [dori]
   Branch:  release
   Config:  release
   Hash:    0xF7261C8C

Hi,

I have written a tool which is based on flirc_repeater (https://github.com/andrewfraley/flirc_repeater). This tool waits for an incoming key which is recognised by Flirc and then re-transmitts a different key using flirc_util sendir based on some routing rules. If you are slow and methodical about pressing the remote buttons, this system works well.

However, if you "spam" one of the remote keys with a cadence of approximately 0.5seconds it looks like the Flirc code that dispatches keys to the host and the functions that allow sendir to work deadlock within the Flirc USB device. Flirc then becomes totally non-responsive and requires an unplug and replug to resolve.

I have tried workaround such as mutexes in the calling code to try and avoid reading from the /dev/input/eventX at the same time as dispatching IR codes via sendir but this has not helped because I cannot control how quickly the user presses the button on the remote.

I am open to workarounds for this including some way to cut and restore power to the USB port to "reboot" the Flirc but so far attempts using for example /sys/bus/usb/drivers/usb/unbind and /sys/bus/usb/drivers/usb/bind have been unsuccessful.

Some further information on this.

Recreation steps

Run the following bash script (Linux)

i=0; while true; do flirc_util sendir --ik=28000 --repeat=1 --csv=0,8953,4415,539,539,568,508,566,510,500,576,569,503,538,542,565,508,569,507,534,541,533,541,568,508,561,515,568,1628,501,576,566,506,538,539,537,1659,569,508,566,510,589,485,536,1663,569,504,538,538,567,509,567,510,566,1630,566,1631,501,1693,504,576,534,1659,569,1628,569,1629,569; echo $i; i=$((i+1)); done

Whilst this script is running, use a remote that you have previously programmed into Flirc and repeatedly press one of the remote buttons repeatedly as quickly as possible (not held down).

Within about 10-20 iterations of the bash script, you will eventually get this error message:

[E] lib/libtransport/hid.c hid_recv_packet(217): Wrong response length = 0
[E] lib/libtransport/hid.c hid_recv_packet(218): hidapi: Success
[E] lib/libtransport/transport.c _recv_packet(127): _recv_packet: recv packet error = -1
[E] lib/libtransport/transport.c _dev_send_cmd(202): recv timeout
Error getting version
device disconnected, can't run command

I'd say this normally takes around 10-20seconds for me. Once this has happened, Flirc is unresponsive.

Following calls to flirc_util result in:

[E] lib/libtransport/hid.c hid_send_packet(150): hidapi: Connection timed out
[E] util/flirc_util/src/cmds/ir_transmit.c sendir(260): Error: could not transmit data

You will see errors like this in the dmesg output:
[Sat Sep 21 11:09:01 2024] usb 1-1.4: usbfs: USBDEVFS_CONTROL failed cmd arp-scan rqt 128 rq 6 len 40 ret -110
[Sat Sep 21 11:09:07 2024] usb 1-1.4: usbfs: USBDEVFS_CONTROL failed cmd arp-scan rqt 128 rq 6 len 40 ret -110

I've also seen this error:

[Thu Sep 19 20:47:07 2024] usb 1-1.4: device descriptor read/64, error -110

Once Flirc has got into this state, it needs to be power cycled to start working again.

@jason Can I provide any further information to help diagnose this?

I can also reproduce this in Windows with the following script which should rule out the Linux USB implementation:

@echo off

set countfiles=100

:loop

set /a countfiles -= 1

"c:\Program Files (x86)\Flirc\flirc_util.exe" sendir --ik=28000 --repeat=1 --csv=0,8953,4415,539,539,568,508,566,510,500,576,569,503,538,542,565,508,569,507,534,541,533,541,568,508,561,515,568,1628,501,576,566,506,538,539,537,1659,569,508,566,510,589,485,536,1663,569,504,538,538,567,509,567,510,566,1630,566,1631,501,1693,504,576,534,1659,569,1628,569,1629,569

echo %countfiles%

if %countfiles% GTR 0 goto loop

Whilst the script is running, press the remote key as described in the previous post. You will notice that eventually the batch file hangs. If you then kill the batch script and attempt to re-run it, you'll see that it can't even execute the first sendir command.

 

I've also noticed that when Flirc gets into this state, it seems to repeatedly dispatch a key event (type = 1, value = 2) in an infinite loop.

@jason Can I do anything else here to assist in tracking down the issue?

Sorry, so in other words, you have a loop transmitting on the remote, you press a button on your remote that is previously paired, and you can get it to hang, is that a summary of the issue?

@jason Yes, that is correct. I can reproduce both with a Linux host and Windows host per the scripts above. Many thanks.

@jason let me know if you need any further information.

@jason Just to clarify, the loop is running on the host computer, driving the Flirc sendir process.

I'm sorry, will have time to play with this maybe end of next week

@jason ok thank you.

@jason have you had a chance to take a look at this?

17 hours ago, frangipan said:

@jason have you had a chance to take a look at this?

No, I have not been able to reproduce this. I jam the button on my remote or press and hold it and can't get it to lock up or throw an error.

Please make sure you are on the latest, here is mine:
3.27.16
FW Version: v4.10.5
   SKU:     Flirc 2.0 [dori]
   Branch:  release
   Config:  release
   Hash:    0xF7261C8C
 

If that doesn't help, the only thing I can think of is using the alternate interface. I ship a tool called irtools that uses a separate USB interface, try that.

Same command arguments, just replace the command. Ships on all platforms.

irtools sendir --ik=28000 --repeat=1 --csv=0,8953,4415,539,539,568,508,566,510,500,576,569,503,538,542,565,508,569,507,534,541,533,541,568,508,561,515,568,1628,501,576,566,506,538,539,537,1659,569,508,566,510,589,485,536,1663,569,504,538,538,567,509,567,510,566,1630,566,1631,501,1693,504576,534,1659,569,1628,569,1629,569;

 

 

@jason thanks, I will try this other tool. If I can still reproduce the problem, I will create a video showing the issue.

@jason I'm on the latest firmware and version of irtools and this is still easy to reproduce. Run the Windows BAT file (swapping out flirc_util.exe with irtools.exe) and whilst it's running, point a remote at Flirc and tap a button (paired or unpaired makes no difference) and Flirc will lock up.

Errors from irtools:

[E] hid_recv_packet(166): hid_recv_packet: wrong report id
[E] hid_recv_packet(167): hidapi: Success
[E] _recv_packet(126): _recv_packet: recv packet error = -1
[E] _dev_send_cmd(208): recv timeout
[E] flirc_init(77): could not set iface

 

 

@jason In my efforts to get this resolved I have purchased a new Flirc which is on an earlier firmware (v4.6.5) and it doesn't suffer the same problem. I can continuously send IR commands using sendir of flirc_util whilst sending IR codes to the device and no crash occurs.

Could you make available to me all the firmwares so that I can upgrade one by one until I encounter the issue? This would then hopefully point us in the right direction for a fix.

@jason Sorry, I presume I can work through the firmware revisions by using the builds on flirc.io?

On 2/2/2025 at 12:49 PM, frangipan said:

@jason Sorry, I presume I can work through the firmware revisions by using the builds on flirc.io?

Best I can do for now, sorry it's ugly. But I believe this is everything: 

https://flirc.com/software/flirc-usb/firmware/

*edit* - You can check which sku you have in the app if you go to file->advanced. 90% of all users have dori.

@jason perfect, many thanks.