#147 irrecord fails on recording new remote (quits after gap detection)

[T. Chelovek]

While recording a SAMSUNG 10340G remotes TV part, irrecord quits after gap detection.

Checking for ambient light  creating too much disturbances.
Please don't press any buttons, just wait a few seconds...

No significant noise (received 0 bytes)

Enter name of remote (only ascii, no spaces) :samsung3
Using samsung3.lircd.conf as output filename

Now start pressing buttons on your remote control.

It is very important that you press many different buttons randomly
and hold them down for approximately one second. Each button should
generate at least one dot but never more than ten dots of output.
Don't stop pressing buttons until two lines of dots (2x80) have
been generated.

Press RETURN now to start recording.
................................................................................
Got gap (89285 us)}

Please keep on pressing buttons like described above.
...............................................................................[

Note the square bracket at the end. It leaves behind an empty ( length 0 )

irrecord-tmp-ywp1NU

Althoug /etc/lirc/lirc_options.conf contains a logfile definition there is no log generated, even if called as

sudo irrecord -U /usr/lib/lirc/plugins -Dtrace2 -O /etc/lirc/lirc_options.conf

Using the irrecord from GIT

[Alec Leamas]

I cannot reproduce this. There should be a tool which could record the raw data you feed irrecord with so we could use that input somewhere else. However, there isn't. Something like irtee...

As for the logfile, irrecord does not obey the logfile directive in [lircd]. As stated in the manpage it's in ~/.cache/irrecord.log (or $XDG_CAXCHE_HOME/irrecord.log).

EDIT: What are irrecord's driver and device (as reported directly after invocation)) ?

[T. Chelovek]

OK, found the log, attaching it...

P.S. wouldn't it be nice if irrecord logged to the location given in lirc_options.conf ?

[Alec Leamas]

OK, you are running ito trouble when trying to get the header... Is this happening for each and every remote you try, or just this one?

No, using lircd's logfile would be a disaster, it needs it's own logs left-alone. And re-directing all applications to the same default logfile would probably be a bad idea anyway.

EDIT: Looking at the code get_header_length in lib/irrecord.c it looks suspicious. Is there any difference if you apply this patch?

diff --git a/lib/irrecord.c b/lib/irrecord.c
index 1344c4e..35d1126 100644
--- a/lib/irrecord.c
+++ b/lib/irrecord.c
@@ -881,7 +881,7 @@ int get_header_length(struct ir_remote* remote, int interactive)
                }
        }
        log_debug("No header found.");
-       return 1;
+       return 0;

[T. Chelovek]

OK, you are running ito trouble when trying to get the header... Is this happening for each and >every remote you try, or just this one?

Just this one.

No, using lircd's logfile would be a disaster, it needs it's own logs left-alone. And re-directing >all applications to the same default logfile would probably be a bad idea anyway.

OK, but I really didn't mean output to the same file, but rather same directory. I am used to search/place logs to /var/log not really hidden places like .cache

EDIT: Looking at the code get_header_length in lib/irrecord.c it looks suspicious. Is there any >difference if you apply this patch?

Good shot ! After patching it works as expected.

While perusing irrecord.c I found that there are other instances of

("No Header

returning 1, you might want to check if they need correcting too.

[Alec Leamas]

OK, but I really didn't mean output to the same file, but rather same
directory. I am used to search/place logs to /var/log not really hidden
places like .cache

/var/log doesn't really work for applications (as opposed to servers) for various reasons, permissions being one of them. And while the ~/.cache is indeed hidden, it's according to the freedesktop standards [1]. This is not the last time you will meet an application which puts files here. I guess.

Good shot ! After patching it works as expected.

Great!

While perusing irrecord.c I found that there are other instances
of("No Header returning 1, you might want to check if they need
correcting too.

Yes... I think I'll just patch this one in the release branch (smallest change) while making a more thorough fix in master.

Thanks for help with bug hunting! There will be a 0.9.4a; in the meantime I presume you now have a working lirc. Still, be aware of [#148 ] which possibly might affect also you (seems that both of you are using RC5 remotes).

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

[Alec Leamas]

Hm., some double-checking... When you say that after patching it "works as expected", what does that mean? A clean failure, or that the remote is identified?

[T. Chelovek]

My expectations are always positive ;-)

So, in fact it means irrecord records the device properly.

Btw can I answer to a bug report via Email ?

[Alec Leamas]

The problem is that I don't understand the code paths here.. Could you possibly attach a log from a successful run also?

Btw can I answer to a bug report via Email ?

Like github? Not sure, but I don't think so. You could always make a try...

[T. Chelovek]

Well, it took a while, but...

I managed to get logs for fail and working case for lirc-0.9.3 as well as lirc-0.9.3git.

For the git variant the behaviour was weird in the "should work" case, as it would let me name a key to be detected, but refuse to detedt it.

P.S. Did you ever visit eastern Germany and die on the return trip ?

[T. Chelovek]

And case #2

[T. Chelovek]

I gave the git version some more tries, only when pressing few keys instead of all randomly during detection would I finally succeed.

[Alec Leamas]

P.S. Did you ever visit eastern Germany and die on the return trip ?

Well, I'm obviously not dead. The rest is a secret well kept ;) Good catch!

And thanks for the logs! Very useful...

That said, this is really tricky. I don't understand this code well enough to actually merge the patch. If you have time, I'd need some more help. It's about the following code around line 1515 in lib/irrecord.c:

if (!get_header_length(remote, interactive)
    || !get_trail_length(remote, interactive)
    || !get_lead_length(remote, interactive)
    || !get_repeat_length(remote, interactive)
    || !get_data_length(remote, interactive))
        state->retval = 0;
return state->retval ==
       0 ? STS_LEN_FAIL : STS_LEN_OK

It seems that the difference the patch makes is that the rest of that statement isn't evaluated. If you have possibilities to run irrecord under gdb and single-step after a breakpoint on the first line (and no patch installed) until it breaks it should be really valuable.

Running under gdb requires some extra steps, partly due to libtool. See CONTRIBUTE.md.

[T. Chelovek]

Good you are still alive :-)

I managed to load irrecord.c into gdb, alas I don't seem to be able to set a break point:

cd lib
sudo libtool --mode=execute gdb irrecord

rewards me with

(gdb) break 1515
No symbol table is loaded.  Use the "file" command.

Now where would I find a "symbol table" to feed gdb with ?

Edit: I obviously needed to compile the stuff :-(

After compile a breakpoint is accepted for line 1515

Stay tuned...

[Alec Leamas]

You should list line 1515. Chance is that it's in the wrong file, Try this:

gdb) break irrecord.c:1515
No source file named irrecord.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (irrecord.c:1515) pending.

[T. Chelovek]

OK now, there seems to be some subtlety about this. I use a directory under home/tchelovek to expand and compile 0.9.3 / 0.9.4 versions. Running irrecord from there gives me the problem, where gap detection completes, but button is not recognized.

I believe the reason to be, that installed ( via pacman package ) is 0.9.4-devel and the defaults are used from there. ( /etc/lirc/lirc_options.conf and the places it points to )

I now reinstalled the 0.9.3 and, running irrecord with gdb get an error after gap detection comes to an end.

Press RETURN now to start recording.
................................................................................
Got gap (89286 us)}

Please keep on pressing buttons like described above.
...............................................................................
Program received signal SIGSEGV, Segmentation fault.
0xb6f8cd5c in get_lead_length () from /usr/lib/libirrecord.so.0
(gdb)

Not sure how to secure the information you need from here :-(

I leave everything as is, so you can direct me to the right places.

[Alec Leamas]

Now, this is actually great. Issue the 'bt' command which will show the backtrace (see CONTRIBUTE.md)

EDIT: OOPS: That's from the system library! Seems that those are preferred before the local ones. The easy path might be to just remove the installed version. You really need to use the libs which you have compiled....

[T. Chelovek]

EDIT: OOPS: That's from the system library! Seems that those are preferred before the local >ones. The easy path might be to just remove the installed version. You really need to use the >libs which you have compiled...

That should fit as I reinstalled a freshly compiled 0.9.3 as package, anyway I will remove the installed stuff altogether and rerun from the locally compiled version..

[T. Chelovek]

(gdb) bt
#0  0xb6f8cd5c in get_lead_length () from /usr/lib/libirrecord.so.0
#1  0xb6f8ea58 in get_lengths () from /usr/lib/libirrecord.so.0
#2  0x0001267c in ?? ()
#3  0xb6e34bb8 in __libc_start_main () from /usr/lib/libc.so.6
#4  0x00012bf0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

[T. Chelovek]

I redid it from zero, to be sure.
Download and compile lirc-0.9.3a from SF

Press RETURN now to start recording.
................................................................................
Got gap (89274 us)}

Please keep on pressing buttons like described above.
...............................................................................
Program received signal SIGSEGV, Segmentation fault.
get_lead_length (remote=remote@entry=0x25d00 <remote>,
    interactive=interactive@entry=0) at irrecord.c:813
813             max_count = max_length->count;
(gdb) bt
#0  get_lead_length (remote=remote@entry=0x25d00 <remote>,
    interactive=interactive@entry=0) at irrecord.c:813
#1  0xb6f76924 in get_lengths (state=0xbefffa70, state@entry=0xbefffa68,
    remote=0x25d00 <remote>, force=<optimized out>, interactive=0)
    at irrecord.c:1529
#2  0x00012430 in mode2_get_lengths (state=0xbefff870, opts=0xbefff8a0)
    at irrecord-ui.cpp:896
#3  main (argc=<optimized out>, argv=<optimized out>) at irrecord-ui.cpp:1127
(gdb)

Edit:

One last iteration for today:

I reran

libtool --mode=execute gdb tools/irrecord
set args -U plugins/.libs -Dtrace2
break irrecord.c:1515
run

As it happens, the break occurs after the first row of dots is completed, afterwards its breaking for every dot of the second row. When simply continuing it runs into the above segfault again.

[Alec Leamas]

hm...what about this patch?

 diff --git a/lib/irrecord.c b/lib/irrecord.c
 index ba2942d..92de703 100644
 --- a/lib/irrecord.c
 +++ b/lib/irrecord.c
 @@ -1310,6 +1310,7 @@ static void compute_lengths_many_signals(struct   lengths_state* state)
  {
         int i;

 +       add_length(&first_1lead, signals[0]);
         merge_lengths(first_1lead);
         for (i = 2; i < state->count - 2; i++) {
                 if (i % 2) {

[T. Chelovek]

Sure looks good

Checking for toggle bit mask.
Please press an arbitrary button repeatedly as fast as possible.
Make sure you keep pressing the SAME button and that you DON'T HOLD
the button down!.
If you can't see any dots appear, wait a bit between button presses.

Press RETURN to continue.
..............................
Toggle bit mask is 0x800.

Successfully written config file samsungtvgdb.lircd.conf
[Inferior 1 (process 30499) exited normally]
(gdb)

[Alec Leamas]

This was a simple copy-paste error + an untested code path. What's worse: I did that mistake...

Many thanks for your help, this would have been impossible to fix without it, in particular without that stacktrace.

Fixed in [6f704b] (release) and [fbfa7d] (master)

[T. Chelovek]

Gee, thank you, for helping me help you :-)

Who knows what scrapped remotes are good for...