#225 Lirc "hangs" for some moments with IrToy

[MisterE2002]

Now sure if it is a bug. The reason is my topic at the irtoy forum:
http://dangerousprototypes.com/forum/viewtopic.php?f=29&t=8459&sid=7c9339754880ea3c7b559f99596afc89

IRW seems to stop detecting keypresses after a couple of hits. If i wait some time it works again.

I am using lirc lircd-0.9.4b, with command:
lircd --nodaemon --dev /dev/irtoy --driver irtoy --loglevel=10

output:
[quote]
lircd-0.9.4b[12539]: Trace1: lircd: Opening log, level: Trace1
lircd-0.9.4b[12539]: Warning: Running as root
lircd-0.9.4b[12539]: Trace: started server socket
lircd-0.9.4b[12539]: Trace1: parsing '/etc/lirc/lircd.conf'
lircd-0.9.4b[12539]: Trace1: parsing '/etc/lirc/lircd.conf.d/CD720.conf'
lircd-0.9.4b[12539]: Trace: parsing remote
lircd-0.9.4b[12539]: Trace1: creating first remote
lircd-0.9.4b[12539]: Info: Using remote: Philips_CD720.
lircd-0.9.4b[12539]: Trace1: flags value: 16386
lircd-0.9.4b[12539]: Trace1: begin codes
lircd-0.9.4b[12539]: Trace1: end codes
lircd-0.9.4b[12539]: Trace1: end remote
lircd-0.9.4b[12539]: Trace: lengths: 113266 113266 89283 90186
lircd-0.9.4b[12539]: Trace: lengths: 113266 113266 89283 90186
lircd-0.9.4b[12539]: Trace: config file read
lircd-0.9.4b[12539]: Notice: lircd(irtoy) ready, using /var/run/lirc/lircd
[/quote]

after "irw"
[quote]
lircd-0.9.4b[12539]: Trace: registering local client
lircd-0.9.4b[12539]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.4b[12539]: Trace: irtoy: init
lircd-0.9.4b[12539]: Trace: irtoy_getversion: Got version V222
lircd-0.9.4b[12539]: Trace: irtoy_reset: Got protocol S01
lircd-0.9.4b[12539]: Trace: Version hw 2, sw 22, protocol 1
[/quote]

The output log is included.

[Bengt Martensson]

It definitely looks like a bug. The driver keeps on sending the IRTOY_LONGSPACE (line 12302ff) a number of times, which makes lircd go nuts.

The patch by Helen Foster, which you mentioned at the IrToy forum, has probably no influence here.

[Bengt Martensson]

I was not able to reproduce the problem on a PC with Fedora24. Data for your evironment is missing from the ticket; from the linked thread you are using RPi.

Please upload a new log with timestamps in it.

Using the mode2 command like

mode2 --driver=irtoy --device=/dev/tty/ACM0

does the problem occur?

[MisterE2002]

I am using a raspberry pi 3, with raspbian 8.
LIRC is compiled using these instructions:
http://dangerousprototypes.com/forum/viewtopic.php?f=29&t=8459#p65220

Your requested Command:
# mode2 --driver=irtoy --device=/dev/irtoy | ts | tee -a log.log

Dec 05 19:48:11 => "play"
after "Dec 05 19:48:13 space 1000000" => "play" (again)
after "Dec 05 19:48:51 space 1000000" => "play" (3 times fast)

With this "mode2" command i do not see strange things. But how can i know?.
I don't know if it registers complete keypresses this way?
I noticed that the "space 1000000" is late.
I can press the next button before it is shown.

---

Again, what i did:

Record 1 keypress:
# unbuffer lircd --nodaemon --dev /dev/irtoy --driver irtoy --loglevel=10 2>&1 | ts %.S | tee /tmp/daemon_1_keypress.log
$ unbuffer irw | ts %.S 2>&1 | tee /tmp/irw_1_keypress.log

Overload:
Pressed the following button in (quick) order "stop", "prev", "next", "play" en finally (after some time) "slow-"
only "stop", "prev" and "slow-" are registered.

# unbuffer lircd --nodaemon --dev /dev/irtoy --driver irtoy --loglevel=10 2>&1 | ts %.S | tee /tmp/daemon_overload.log
$ unbuffer irw | ts %.S 2>&1 | tee /tmp/irw_overload.log

[Bengt Martensson]

Unfortunately, I still do not know what goes on. It appears not to happen on a "fat" PC, only on the RPi, and then only occasionally, so it might be a timing problem. It appears as that the toy sends 0xFFFF when not expected. (The good news is that the system recovers after a few seconds.) It may be worthwile to try the
inofficial firmware "2.4"; please report.

[MisterE2002]

the firmware update fails. posted results in your link

[Bengt Martensson]

Any news? How are we going to procede?

[MisterE2002]

Device take to much valuable time to figure out.

[Bengt Martensson]

In the D.P. forum it is claimed that increasing the timesouts solves the problem. ACK/NAK? Should we accept that as a solution?

Setting timeout to 2 seconds for a locally connected simple devices feels somewhat uncool to me...

[Bengt Martensson]

I finally decided to find out what's going on, and was able to reproduce the problem on an RPi3. Flashing the abovementioned "rogue" firmware "2.4", and the problem was not to be seen any more.

I suggest that we consider the problem solved with this, and close the ticket.

[Alec Leamas]

Thanks for looking into this! Closing.