Re: girs driver issues

[Bengt M. <bu...@be...>]

[The answer was sent to me, not the list. I shall assume that this was 
unintended and I answer to the list.]

On 2020-03-15 14:01, Tim Pletcher wrote:
> Bengt,
> 
> Thank you for looking into this.

>     This is weird. On line 84, a sensible line is received, consisting of
>     two copies of the expected signaö. The first half is decoded (line
>     199ff), then for some reason, lircd goes in siesta for 10 seconds (why
>     is line 203 empty??) and (line 208ff) it decodes the rest -- without
>     recognizing it as repeat.
> 
> Unknown why line 203 is empty.  I went back to the original file to 
> ensure i didn't accidentially insert a new line and found was generated 
> this way by lircd.  Empty lines seem to occur periodically (e.g. line 
> 319, 474....)
> 
>     Try changing (in GirsLiteConfig.h) DEFAULT_RECEIVE_ENDINGTIMEOUT t0 30
>     and undefine PARAMETERS and report back.
> 
> I disabled parameters & led modules and set receive_endingtimeout to 
> 30.  With this setting, irw / lircd no longer correctly interpret 
> incoming remote keys.

Which one was incorrectly received? More importantly, did in solve the 
problem with the Samsung signals?

I may have to take a close look, but not today...

>  I noticed in my testing before that lircd was 
> setting receive_endingtimeout to 61 at startup.  On my other machine, it 
> gets set to something like 100 ms.  Is this value derived from analyzing 
> the expected length of signals associated with the configured lircd.conf 
> remote files?

Lircd scans all the remotes in lircd.conf, and somehow computes that 
number as the smalles or largest number of ... something. (Must look it 
up...)

Does it work for you with a standard, say NEC1 setup?