[kire1980]

I am experiencing some problems using Lirc on the last Openelec builds.

For the record, I'm using Openelec version I'm using is 2.99.3 (from 21 Feb) on a 256MB Pi. I have a TSOP receiver connected to the GPIO and have configured the Lircd.conf file. The remote control I am using is a "Netgear Universal Remote", which uses RC-5 extended codes, nothing special. I have disabled the use of HDMI CEC remote control.

The Lircd.conf look as follows (I've only posted the top section):

Code:

begin remote

  name  Netgear_Universal_Remote
  bits           13
  flags RC5|CONST_LENGTH
  eps            30
  aeps          100

  one           889   889
  zero          889   889
  plead         889
  gap          113721
  toggle_bit_mask 0x800
  frequency    36000
  duty_cycle   50

      begin codes
          KEY_HOME                 0x15D2
          KEY_INFO                 0x15D7
          KEY_UP                   0x15D4
          .....

There are two problems I have:

1.
The remote control stops working after starting a movie. When I check using 'irw' there is no response, no commands are received/processed. Only way to stop the movie is by rebooting.

2.
Sometimes remote 'double presses' are received.
Example, when pressing a single button on the remote once (very shortly), irw shows:

Code:

6a 1 KEY_RIGHT devinput
6a 2 KEY_RIGHT devinput
6a 3 KEY_RIGHT devinput
6a 4 KEY_RIGHT devinput
6a 5 KEY_RIGHT devinput
6a 6 KEY_RIGHT devinput
6a 0 KEY_RIGHT_UP devinput

After rebooting, sometimes irw outputs a somewhat corrected received command, altough it seems the toggle_bit is not handled correctly. Anyway, it seems to be quite random what happens after a reboot, because the other time it's the same as above.

Code:

00000000000015d1 00 KEY_RIGHT Netgear_Universal_Remote
00000000000015d1 01 KEY_RIGHT Netgear_Universal_Remote

In addition to the 2.99.3 build, I also tried the latest test build 13378, and some older ones, but the problem remains.

It worked fine when I setup Lirc a few months ago (unfortunately I don't remember the build I used back then...).

Any ideas what's causing this and how it can be solved?

I can post more info if needed, just let me know what's needed.

Thanks!

[navster]

I had some fun and games setting up my remote too but it seems to be working fine with latest nightly and stable builds. Are you using the autostart.sh script from the openelec forums and have you tried going thourgh the irrecord process again such as below:

irrecord -d /dev/lirc0 -f remote-test.conf

[kire1980]

Yes, I tried irrecord again, made no difference.

My autostart.sh looks like this:

Code:

#!/bin/sh
(kill -9 $(pidof lircd); \
modprobe lirc_rpi; \ #for new libgpio version
/usr/sbin/lircd --driver=default --device=/dev/lirc0 --uinput --output=/var/run/lirc/lircd --pidfile=/var/run/lirc/lircd-lirc0.pid /storage/.config/lircd.conf; \
)&

exactly as suggested on http://openelec.tv/forum/124-raspberry-p...d-snapshot.

I just tried release r12457 (found on above url), and it seems to work fine there, except from the fact that after video start, there is no response to the remote, the output of irw stays blank, no keys are received...
Just installed r13387 as well, same problem, multiple keypresses are recorded and still no remote response after video start.
(by the way, I am not overclocking, simply using stock settings, altough enabling overclock doens't change anything)...

What I don't get is why this happens randomly, the behaviour is different after every reboot?

[edit]
Seems to be I'm not the only one having issues with the remote... See: http://openelec.tv/forum/103-infared-rem...mitstart=0

[navster]

Perhaps the alternate autostart.sh is worth a try:

Code:

#!/bin/sh
(modprobe lirc_rpi; \
while [ ! -e /var/run/lirc/lircd-lirc0 ]; do
     sleep 1; \
done
if [ -h /var/run/lirc/lircd ]; \
    then logger autostart: lircd socket already linked! ;\
else
    logger autostart: linking lircd socket ... ; \
    rm /var/run/lirc/lircd; \
    ln -s /var/run/lirc/lircd-lirc0 /var/run/lirc/lircd; \
fi)&

I do however suspect the updated Broadcom firmware on the newer builds is mangling your remote behaviour. During my setup irrecord did not pick up the correct toggle bit mask which I eventually corrected from the official lirc files found here:

http://lirc.sourceforge.net/remotes/

For reference I used a spare Sky HD remote I had lying around and here are my respective files:

/storage/.config/lircd.conf

Code:

begin remote

name                    SKY_HD
bits                    8
flags                   RC6|NO_HEAD_REP|CONST_LENGTH
eps                     30
aeps                    100
header                  2697   876
one                     456   432
zero                    456   432
pre_data_bits           17
pre_data                0x3FA3
gap                     149908
toggle_bit              0
rc6_mask                0x100000

begin codes

KEY_PLAY                0xC1
KEY_PAUSE               0xDB
KEY_STOP                0xC0
KEY_FORWARD             0xD7
KEY_REWIND              0xC2
KEY_LEFT                0xA5
KEY_RIGHT               0xA4
KEY_UP                  0xA7
KEY_DOWN                0xA6
KEY_OK                  0xA3
KEY_PAGEUP              0xDF
KEY_PAGEDOWN            0xDE
KEY_BACK                0x7C
KEY_MENU                0x33
KEY_INFO                0x34
KEY_1                   0xFE
KEY_2                   0xFD
KEY_3                   0xFC
KEY_4                   0xFB
KEY_5                   0xFA
KEY_6                   0xF9
KEY_7                   0xF8
KEY_8                   0xF7
KEY_9                   0xF6
KEY_0                   0xFF

end codes

end remote

/storage/.xbmc/userdata/Lircmap.xml

Code:

<lircmap>

<remote device="SKY_HD">

<play>KEY_PLAY</play>
<pause>KEY_PAUSE</pause>
<stop>KEY_STOP</stop>
<forward>KEY_FORWARD</forward>
<reverse>KEY_REWIND</reverse>
<left>KEY_LEFT</left>
<right>KEY_RIGHT</right>
<up>KEY_UP</up>
<down>KEY_DOWN</down>
<select>KEY_OK</select>
<pageplus>KEY_PAGEUP</pageplus>
<pageminus>KEY_PAGEDOWN</pageminus>
<back>KEY_BACK</back>
<menu>KEY_MENU</menu>
<info>KEY_INFO</info>
<one>KEY_1</one>
<two>KEY_2</two>
<three>KEY_3</three>
<four>KEY_4</four>
<five>KEY_5</five>
<six>KEY_6</six>
<seven>KEY_7</seven>
<eight>KEY_8</eight>
<nine>KEY_9</nine>
<zero>KEY_0</zero>

</remote>

</lircmap>

Good luck

[kire1980]

Okay, thanks a lot for your help
the alternative autostart.sh fixed the irregular behaviour after reboots and also fixed the double key presses.
Now menu navigiation is possible again, also with the latest nightly!

However, the issue of the remote control no longer working after starting a video still exists...

I did manage to narrow the problem down a bit, and it doesn't seems to be caused by playing a video, but seems to be related to disk access. I have a 500GB hdd connected to the Pi using a USB-SATA adapter. The hdd is detected perfectly and accessing the disc is flawless (filesystem is ext3), EXCEPT from the fact that during disk access the remote is unresponsive.

I've verified this by checking irw output dufring video play, but also while copying a large file from my windows PC to the hdd trough samba access in windows. In both cases irw shows no output. Also during browsing through the hdd file system in the XBMC menu, sometimes the remote doesn't work. Same issue I guess...

Since 'normal' disk access on the SD-card works fine, could this be caused by the USB adapter? Maybe something is blocking GPIO access during USB transfers ?

I'm just guessing here, and hopefully someone knows what is going on here. Any ideas?

[Tompen]

IIRC I experienced the same a couple months ago. If I killed lirc, then run command:
mode2 -d /dev/lirc0
(this is same as irw, but shows everything the TSOP see = not only valid remote key presses that lirc can understand)

When XBMC was doing nothing, I could see output only whenever I pressed a key on the remote.

When XBMC was playing a movie, the output from above command was constantly giving random outputs.
In my case I solved it by connecting my hdd to a usb hub that had an external power adapter.
With more stable power my TSOP seems to behave better.

[kire1980]

Ok, seems to similar indeed.

I'm going to check the power supplies. The hdd (which is a 3.5" seagate hdd) is externally powered by a separate 5V/12V supply, but the USB-SATA converter is still powered by the Pi's USB port. I have the Model B, so without the fuses in the +5v lines. Anyway, I'll try a powered usb hub as well, see if it makes a difference.

Stopping lirc and checking with mode2, good one, I'll try this as well.

Thanks for the ideas! I'll post the results after testing.

[navster]

I would concur with Tompen, your issue is almost certainly a power related one, playing the video draws extra power from your RPi to accommodate your converter\hdd and this is not leaving enough power for your IR system to function. I personally dont have this issue as all of my content is accessed via wifi, which I am currently wrestling with reliable live TV .....

Another useful test would be to see if your remote works whilst accessing wifi only content such as a network share our YouTube

[kire1980]

Good news,the problem has been solved!

It was indeed caused by the power supply. Although the 12V was okay, the 5V dropped to much when the hdd was accessed (either by playing video or simply accessing/copying files). The total current drawn by the Pi and the hdd combined was too much for the supply. I replaced it with a heavier one and now the remote is also working correctly during video play or file access.

The trick to kill lirc and checking the output of mode2 was very helpful. Indeed in my case as well, mode2 was displaying a lot of random junk during disk access. Replacing the power supply fixed this.

Thanks a lot for your help