Quantcast

lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk
Hi,
I’m developing small MythTV appliance (MiniMyth2) and decided to upgrade (highly stable) lirc 0.9.0 to 0.9.4b.
MiniMyth2 heavily using irsend to control other multimedia equipment.  
After some adaptations I got all working with 0.9.4.

Unfortunately I discovered annoying issue: for some remote types irblaster works very unreliably (1 from 10 sends is recognized by target equipment).

Interesting is that LED diode on blaster blinks really slowly for sends when commands are unrecognized and normally fast (very similarly to 0.9.0) when command is correctly sent and recognized by target.
This tells me that issue looks like sometimes irsend „plays” IR command with too „slow speed”.
Also interesting is that I have this issue only with some remotes (i.e. Sharp TV).
Other remotes (i.e. Sony amplituner) works like on 0.9.0 (100% reliably).

lircd.conf for falling Sharp looks like this:

begin remote
  name          sharp_46x20e
  bits          15
  flags         SPACE_ENC
  eps           30
  aeps          100
  one           480  1680
  zero          480  560
  ptrail        480
  gap           10000
  repeat_bit    0
  frequency     38000

  begin codes
    power_tv    0x41A2
    power_tv_r  0x425D
    tv_vol+     0x40A2
    tv_vol+_r   0x435D
    tv_vol-     0x42A2
    tv_vol-_r   0x415D
    mute        0x43A3
    mute_r      0x405C
    1           0x4202
  end codes
end remote

I’m out of ideas how to track & resolve this issue. Now this effectively blocks me with going with 0.9.4 and forcing to stay on prehistoric (albeit very stable) 0.9.0.

All advices are very welcomed!
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Alec Leamas


On 10/02/17 18:43, Piotr Oniszczuk wrote:

> Hi,
> I’m developing small MythTV appliance (MiniMyth2) and decided to upgrade (highly stable) lirc 0.9.0 to 0.9.4b.
> MiniMyth2 heavily using irsend to control other multimedia equipment.
> After some adaptations I got all working with 0.9.4.
>
> Unfortunately I discovered annoying issue: for some remote types irblaster works very unreliably (1 from 10 sends is recognized by target equipment).
>
> Interesting is that LED diode on blaster blinks really slowly for sends when commands are unrecognized and normally fast (very similarly to 0.9.0) when command is correctly sent and recognized by target.
> This tells me that issue looks like sometimes irsend „plays” IR command with too „slow speed”.
> Also interesting is that I have this issue only with some remotes (i.e. Sharp TV).
> Other remotes (i.e. Sony amplituner) works like on 0.9.0 (100% reliably).

hm... Which driver/device are you using?

I also understand this as you are testing 0.9.0 and 0.9.4 on the same
kernel, right? Which kernel, then?

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk

>
> Well, if you havn't a file driver something is broken in your installation. What does
>
>  $ lirc-lsplugins | grep file
>
> tell you?
>
>
>
> Cheers!
>
> --alec

Ok - file.so was missed in system image.
Now logging to file works.
Seding command to TV (equipment where is have issue) gives following data in log file like below.

You mention we want to investigate its root cause: kernel or in lirc.
I have perfectly working lirc 0.9.0 with exactly the same kernel - so 0.9.4 is regression for me.
Is 0.9.4 using different kernel code to serve IR blaster than 0.9.0?

Anyway - what now I should do with this log file?


pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 10000
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 10000
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 10000
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 1680
pulse 480
space 560
pulse 480
space 1680
pulse 480
space 10000
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk
Hmm - basically I see no movements regarding this regression.
Looking on SourceForge I see only devs can create bug ticket.
So I’m courious: will it be followed as bug or….
How can i help to move forward?
Currently 0.9.4 is not usable as default in my distro.

>
> Ok - file.so was missed in system image.
> Now logging to file works.
> Seding command to TV (equipment where is have issue) gives following data in log file like below.
>
> You mention we want to investigate its root cause: kernel or in lirc.
> I have perfectly working lirc 0.9.0 with exactly the same kernel - so 0.9.4 is regression for me.
> Is 0.9.4 using different kernel code to serve IR blaster than 0.9.0?
>
> Anyway - what now I should do with this log file?
>
>
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 10000
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 10000
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 10000
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 1680
> pulse 480
> space 560
> pulse 480
> space 1680
> pulse 480
> space 10000


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Bengt Martensson-2
On 02/21/17 21:12, Piotr Oniszczuk wrote:
> Hmm - basically I see no movements regarding this regression.
> Looking on SourceForge I see only devs can create bug ticket.

AAIK, anyone with an account on Sourceforge can create tickets; I did
this two days ago.

> So I’m courious: will it be followed as bug or….
> How can i help to move forward?
> Currently 0.9.4 is not usable as default in my distro.
>
>>
>> Ok - file.so was missed in system image.
>> Now logging to file works.
>> Seding command to TV (equipment where is have issue) gives following data in log file like below.

Appears that the signal rendering is working.

>> You mention we want to investigate its root cause: kernel or in lirc.

The kernel "bug" (which has been officially declared to be non-bug)
relates to decoding; space and pulses may not be interleaving. So this
does not apply-

>> I have perfectly working lirc 0.9.0 with exactly the same kernel - so 0.9.4 is regression for me.

Your lircd.conf looks suspect to me, i.e. does not look that something
that controls a Sharp TV. Exactly what Sharp TV do you have?

>> Is 0.9.4 using different kernel code to serve IR blaster than 0.9.0?

Alec already asked you what driver/device you are using...

Greetz,

Bengt


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk
Bengt, pls see inline

> Wiadomość napisana przez Bengt Martensson <[hidden email]> w dniu 23.02.2017, o godz. 10:13:
>
> On 02/21/17 21:12, Piotr Oniszczuk wrote:
>> Hmm - basically I see no movements regarding this regression.
>> Looking on SourceForge I see only devs can create bug ticket.
>
> AAIK, anyone with an account on Sourceforge can create tickets; I did
> this two days ago.

Ah ok - I wasn’t aware of that.
Should I create ticket or any of devs will do so?

>
>> So I’m courious: will it be followed as bug or….
>> How can i help to move forward?
>> Currently 0.9.4 is not usable as default in my distro.
>>
>>>
>>> Ok - file.so was missed in system image.
>>> Now logging to file works.
>>> Seding command to TV (equipment where is have issue) gives following data in log file like below.
>
> Appears that the signal rendering is working.
Good to hear this.

I’m not specialist with LIRC internals - but if we know that:
-signal rendering by LIRC 0.9.4 seems to be OK
-my kernel (4.9.10) with my LIRCD config for SharpTV works OK on 0.9.0
-my kernel (4.9.10) with my LIRCD config for SharpTV works NOK on 0.9.4

then I conclude issue might be:
a\ LIRC 0.9.4 uses kernel API in different way than 0.9.0
b\ LIRC 0.9.4 uses different kernel API than 0.9.0
 

>
>>> You mention we want to investigate its root cause: kernel or in lirc.
>
> The kernel "bug" (which has been officially declared to be non-bug)
> relates to decoding; space and pulses may not be interleaving. So this
> does not apply-
>
>>> I have perfectly working lirc 0.9.0 with exactly the same kernel - so 0.9.4 is regression for me.
>
> Your lircd.conf looks suspect to me, i.e. does not look that something
> that controls a Sharp TV. Exactly what Sharp TV do you have?
Config file is created by me via irrecord long time ago - mainly because none config found in Internet was not working reliably.
Config I created & attached works 100% reliable for me on 0.9.0 - so I’m using it as kind of reference config.
 

>
>>> Is 0.9.4 using different kernel code to serve IR blaster than 0.9.0?
>
> Alec already asked you what driver/device you are using…
Right.
It looks like we have 2 parallel comm.channels here: mailing list & Alec PM.
Here is what I replayed to Alec via PM:

>> Alec,
>> Thx for quick replay.
>>
>> Kernel is 4.9.8.
>>
>> Remote is MCE USB remote.
>> Feb 10 18:47:05 (none) user.info kernel: Registered IR keymap rc-rc6-mce
>> Feb 10 18:47:05 (none) user.info kernel: input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/rc/rc0/input5
>> Feb 10 18:47:05 (none) user.info kernel: rc rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/rc/rc0
>>
>> Kerel module is mceusb.
>>
>> My lirc options:
>>
>> [lircd]
>> nodaemon        = False
>> driver          = default
>> device          = /dev/lurch
>> output          = /var/run/lirc/lircd
>> pidfile         = /var/run/lircd.pid
>> plugindir       = /usr/lib/lirc/plugins
>> permission      = 666
>> allow-simulate  = Yes
>> repeat-max      = 600
>>
>> [lircmd]
>> uinput          = False
>> nodaemon        = False
>>
>> [modprobe]
>> #modules        = [lircd_dev, lirc_sir...]




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Bengt Martensson-2
On 02/23/17 10:32, Piotr Oniszczuk wrote:
> Bengt, pls see inline
>
>> Wiadomość napisana przez Bengt Martensson <[hidden email]> w dniu 23.02.2017, o godz. 10:13:
...

>>>> Is 0.9.4 using different kernel code to serve IR blaster than 0.9.0?
>>
>> Alec already asked you what driver/device you are using…
> Right.
> It looks like we have 2 parallel comm.channels here: mailing list & Alec PM.
> Here is what I replayed to Alec via PM:
>
>>> Alec,
>>> Thx for quick replay.
>>>
>>> Kernel is 4.9.8.
>>>
>>> Remote is MCE USB remote.
>>> Feb 10 18:47:05 (none) user.info kernel: Registered IR keymap rc-rc6-mce
>>> Feb 10 18:47:05 (none) user.info kernel: input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/rc/rc0/input5
>>> Feb 10 18:47:05 (none) user.info kernel: rc rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/rc/rc0
>>>
>>> Kerel module is mceusb.

Please do the following: Install IrScrutinizer 1.3 or later.
https://github.com/bengtmartensson/harctoolboxbundle/releases/tag/Version-1.3 
. Use that, using /dev/lirc as capturing device to capture a few of the
signals from your remote. This should likely identify the signals and
their protocol. You can also transmit them again with IrScrutinizer,
using /dev/lirc. Does this work? If so, capture the rest of the keys and
use IrScrutinizer to generate a lircd.conf for you.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk

>
> Please do the following: Install IrScrutinizer 1.3 or later.
> https://github.com/bengtmartensson/harctoolboxbundle/releases/tag/Version-1.3 
> . Use that, using /dev/lirc as capturing device to capture a few of the
> signals from your remote. This should likely identify the signals and
> their protocol. You can also transmit them again with IrScrutinizer,
> using /dev/lirc. Does this work? If so, capture the rest of the keys and
> use IrScrutinizer to generate a lircd.conf for you.
>
> Greetz,
>
> Bengt
>

Bengt,

I give run for IrScrutinizer.
System where I have IR dongle connected is appliance with minimal size PXE booted OS - so running IrScrutinizer is impossible (no Java, etc).
Therefore I launched lircd on this system in TCP listening mode and run IrScrutinizer on remote machine (MacBook).
lidcd was launched with following cmd line:

/usr/sbin/lircd —device=/dev/lirc0 --driver=default --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lircd-lirc0.pid --listen=8765

On IrScrutinizer I select SendingHW/Lirc, provided IP/port.
Reload gives me list of my remotes - so I can select my „sharp_46x20e”.
I select „power_tv” command and press „Send”.
I do test on 2 different platforms: (Intel AtomD525 and IntelNUC i5)

Results:

IntelNUC i5:
0.9.0 - OK
0.9.4 - OK

Atom D525
0.9.0 - OK
0.9.4 - NOK

This is interesting as 0.9.4 works OK in i5 - but not on D525.

Well - I’m out of ideas why this….
   


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Bengt Martensson-2
On 02/23/17 21:41, Piotr Oniszczuk wrote:

>
>>
>> Please do the following: Install IrScrutinizer 1.3 or later.
>> https://github.com/bengtmartensson/harctoolboxbundle/releases/tag/Version-1.3
>> . Use that, using /dev/lirc as capturing device to capture a few of the
>> signals from your remote. This should likely identify the signals and
>> their protocol. You can also transmit them again with IrScrutinizer,
>> using /dev/lirc. Does this work? If so, capture the rest of the keys and
>> use IrScrutinizer to generate a lircd.conf for you.
>>
>> Greetz,
>>
>> Bengt
>>
>
> Bengt,
>
> I give run for IrScrutinizer.
> System where I have IR dongle connected is appliance with minimal size PXE booted OS - so running IrScrutinizer is impossible (no Java, etc).

Hmm, there is no /dev/lirc on the MacBook? Try to find a machine that
you can plug the donle to, and having it showing up as /dev/lirc, and
that runs IrScrutinizer. Then you can capture, test-send and generate a
lircd.conf on that machine.

> Therefore I launched lircd on this system in TCP listening mode and run IrScrutinizer on remote machine (MacBook).
> lidcd was launched with following cmd line:
>
> /usr/sbin/lircd —device=/dev/lirc0 --driver=default --output=/var/run/lirc/lircd-lirc0 --pidfile=/var/run/lircd-lirc0.pid --listen=8765
>
> On IrScrutinizer I select SendingHW/Lirc, provided IP/port.
> Reload gives me list of my remotes - so I can select my „sharp_46x20e”.
> I select „power_tv” command and press „Send”.
> I do test on 2 different platforms: (Intel AtomD525 and IntelNUC i5)

This is just another way of irsend-ing.

Greetz,

Bengt

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk

> Wiadomość napisana przez Bengt Martensson <[hidden email]> w dniu 23.02.2017, o godz. 22:57:
>
>>
>
> Hmm, there is no /dev/lirc on the MacBook? Try to find a machine that
> you can plug the donle to, and having it showing up as /dev/lirc, and
> that runs IrScrutinizer. Then you can capture, test-send and generate a
> lircd.conf on that machine.
>
>>

Bengt,

Forgive me but I’m a bit lost here.
How running IrScrutinizer + LIRC HW on different hardware/OS can help with resolving LIRC issue on particular hardware?

Issue I have is (so far investigation shows following):
0.9.4 regression on Intel Atom D525 (and ION1 as well).

Lets summarize:
0.9.0 works all HW & all remote configs i have.
Also multiple users of my distribution are not reporting any issues with 0.9.0

0.9.4 has issue with selected remotes and on selected HW (Intel Atom).
i5 NUC seems to be fine.

Note: My 0.9.0 vs 0.9.4 tests are on:
- exactly the same environment (HW, kernel libs; I simply recompile lirc)
- with exactly the same lidcd remote definitions.

If You advice to use IrScrutinizer to generate new remote lircd config - then I disagree with this approach.
Changing config to mask 0.9.4 regression is not solving problem.
It may work for me - I have many distro users using various remotes and currently 0.9.4 give me high probability that somebody else will also meet this regression - exactly like me.

Lets find root cause of this issue!

br  



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Alec Leamas
Hi!

Sorry for long delay, busy doing other things (a. k. a. having a life ;) )

On 24/02/17 16:46, Piotr Oniszczuk wrote:

> If You advice to use IrScrutinizer to generate new remote lircd config - then I disagree with this approach.
> Changing config to mask 0.9.4 regression is not solving problem.
> It may work for me - I have many distro users using various remotes and currently 0.9.4 give me high probability that somebody else will also meet this regression - exactly like me.
>
> Lets find root cause of this issue!

Yup. Still, Bengt might very well be right since one possible
explanation might be that the used config files' timing  info is not
exactly right which means that it's works more or less my luck in
certain cases, and not in others. So, following that path to re-check
the config files might an important step.

Others than that, I cannot say that there is something obviously wrong
with the data leaving lirc and entering the kernel in 0.9.4. Your
recorded data looks sound at a glance, repeating the same code a number
of times. Unfortunately, there is no file driver or corresponding
functionality in 0.9.0 to make a comparison possible.

For a more detailed analyze we need to know the exact config file and
button pressed when generating this log (sorry if you already provided
this, bit I don't find it in the thread).

You could also try the attached patch to 0.9.0. Given the same config
and input as used when creating the 0.9.4 log file, this should log the
sent data using 0.9.0 which could be compared to the data from 0.9.4
file driver.

One thing which comes into my mind is #265 - possibly, this could affect
you and making a check with restored code_length is certainly worth a try.


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

0.9.0-debug.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Piotr Oniszczuk

> Wiadomość napisana przez Alec Leamas <[hidden email]> w dniu 05.03.2017, o godz. 10:27:
>
> Hi!
>
> Sorry for long delay, busy doing other things (a. k. a. having a life ;) )
>
> On 24/02/17 16:46, Piotr Oniszczuk wrote:
>
>> If You advice to use IrScrutinizer to generate new remote lircd config - then I disagree with this approach.
>> Changing config to mask 0.9.4 regression is not solving problem.
>> It may work for me - I have many distro users using various remotes and currently 0.9.4 give me high probability that somebody else will also meet this regression - exactly like me.
>>
>> Lets find root cause of this issue!
>
> Yup. Still, Bengt might very well be right since one possible explanation might be that the used config files' timing  info is not exactly right which means that it's works more or less my luck in certain cases, and not in others. So, following that path to re-check the config files might an important step.
>
> Others than that, I cannot say that there is something obviously wrong with the data leaving lirc and entering the kernel in 0.9.4. Your recorded data looks sound at a glance, repeating the same code a number of times. Unfortunately, there is no file driver or corresponding functionality in 0.9.0 to make a comparison possible.
>
> For a more detailed analyze we need to know the exact config file and button pressed when generating this log (sorry if you already provided this, bit I don't find it in the thread).
>
> You could also try the attached patch to 0.9.0. Given the same config and input as used when creating the 0.9.4 log file, this should log the sent data using 0.9.0 which could be compared to the data from 0.9.4 file driver.
>
> One thing which comes into my mind is #265 - possibly, this could affect you and making a check with restored code_length is certainly worth a try.
>
>
> Cheers!
>
> --alec
> <0.9.0-debug.diff>------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Alec,
Sorry for silence - i was on business trip.
I tried 0.9.4b with reverted 4053290e5d435 - no difference.
Also I was trying to play with 0.9.0 + attached debug patch.
Unfortunately file in /tmp/ has always 0b size…
Are there any special preconditions to have debugging with this patch?

 
 
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: lirc upgrade 0.9.0->0.9.4: irsend works very unreliably - but only for some remotes

Alec Leamas
Hi!

On 12/03/17 13:42, Piotr Oniszczuk wrote:

> Alec,
> Sorry for silence - i was on business trip.
> I tried 0.9.4b with reverted 4053290e5d435 - no difference.
> Also I was trying to play with 0.9.0 + attached debug patch.
> Unfortunately file in /tmp/ has always 0b size…
> Are there any special preconditions to have debugging with this patch?
>

Let's stop apologizing for silence - seems that we all have things to do :)

Anyway, this is a complicated issue and the easy shots in the dark
doesn't seem to make it. Still, if we are lucky, the problem is
introduced after 0.9.2 - in this case a simple git bisect should reveal
the error.

Have you read the CONTRIBUTE.md file with the info how to run a built
source tree without installing it? If not, could you please read that
file and setup a test environment where you can build and run lircd
without installation?

And, with this in place, check if the  lirc-0.9.2a tag also is broken in
this respect?

If you need with the details, just let me know!


Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Loading...