Kodi Community Forum

Full Version: Solved: [XBMCbuntu 13.0 Gotham] IR remote stops working when CPU1 runs 100%
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Edited and marked solved: to make a long story short. Lirc is not working properly in the 13.2 live version. I had to replace it with inputlirc and changed my mapping in xbmc. Lirc is running into cpu issues causing events to be missed.


Today I upgraded to XBMCbuntu 13.0 and I notice something really strange with my remote. I am running this on a brand new ASRock Mini 180D. To be exact I am running this on a persistent live usb disk, created with unetbootin. I boot this with the "try xbmc" option.

What happens is as follows. Initially after booting, my remote sometimes is not responding at all. Most of the times it is working as expected. Initially it is fast responding, but after a while it really is slow. I have to hold a remote key, for about 5 seconds, before XBMC responses at all. This lagging especially happens when I am in the settings menu. It is not related to a skin, or anything else because I tried "hybrid" and the default confluence. It is also not that XBMC is hanging, because when I use the USB wireles keyboard (using bluetooth for internal communication, so no IR interference is here), xbmc responses very fast.

So here is the interesting part. When I disconnect the USB keyboard, (so removing the USB sensor from my USB port), the remote control is very fast responding. And does not lag in the beginning. However after a while, it also is starting to lag, but not as big with the keyboard connected.

Here is some info from the debug log:
20:05:41 T:140496244500416 DEBUG: LIRC: Update - NEW at 1794728:000000037ff07be0 00 KEY_DOWN mceusb (KEY_DOWN)
20:05:41 T:140496244500416 DEBUG: OnKey: 167 (0xa7) pressed, action is Down

Note that I pressed the "down" button on the remote "3" times, but only one is registered.

Any help would be great, otherwise I need to revert back to live 12.2 which does not lag at all.

P.s. here is some info from dmesg:

[ 26.018650] Registered IR keymap rc-rc6-mce
[ 26.019001] input: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/pnp0/00:03/rc/rc0/input4
[ 26.019237] rc0: Nuvoton w836x7hg Infrared Remote Transceiver as /devices/pnp0/00:03/rc/rc0
[ 26.037141] IR NEC protocol handler initialized
[ 26.041760] IR RC5(x) protocol handler initialized
[ 26.057167] IR RC6 protocol handler initialized
[ 26.070640] IR JVC protocol handler initialized
[ 26.074941] IR Sony protocol handler initialized
[ 26.080660] IR SANYO protocol handler initialized
[ 26.091645] IR MCE Keyboard/mouse protocol handler initialized
[ 26.093156] input: MCE IR Keyboard/Mouse (nuvoton-cir) as /devices/virtual/input/input5
[ 26.093504] nuvoton_cir: driver has been successfully loaded
[ 26.119513] lirc_dev: IR Remote Control driver registered, major 251
[ 26.132277] rc rc0: lirc_dev: driver ir-lirc-codec (nuvoton-cir) registered at minor = 0
[ 26.132288] IR LIRC bridge handler initialized
Another thing I now notice is that after a while, the remote is responsding fast again. Still with the USB disconnected.

So please note that whenever I have any wireless USB keyboard connected (I have tried two of them), the lag is there and does not resolve itself. But when there is NO USB keyboard connected, it works as it should, most of the time.
Here is also a new update. I went into my "system information" screen and there I noticed that somehow CPU1 was running at a 100% cpu. I have no clue why, but when this was occuring, the remote was no longer working at all. So it looks like that the events are no longer getting through to the xbmc system. When I reset xbmc via: " sudo restart lightdm" it went back to normal, and the remote works again as expected.

So I suspect this issue is actually cause by NO CPU power left.

One of the things I am wondering, if I should do this, taken from http://forum.xbmc.org/showthread.php?tid=195778:

2.1 Let the kernel pass the signal through to LIRC
The first one will allow you to follow the traditional LIRC guides. All you have to do is execute

modprobe ir-lirc-codec
ir-keytable -p LIRC

You can add 'ir-lirc-codec' to /etc/modules and the ir-keytable command to /etc/rc.local (or equivalent) if you want to make it persistent.

This should allow irw to function as it has always done, so you can now use hardware.conf, lircd.conf and irrecord as described in the traditional lirc howtos.

If you choose this path, you probably won't be able to emulate keypresses and assign different actions to the same button (I think). You will have to use Lircmap.xml instead of keyboard.xml and the latter looks much more versatile (at least the vanilla ones).

But I don't want to break anything first.
I noticed that xbmc was again running at 100% (actually 110, since it is dual). These are the last log notes:

23:06:26 T:140374219679488 NOTICE: Thread JobWorker start, auto delete: true
23:06:54 T:140374211286784 NOTICE: Thread BackgroundLoader start, auto delete: false
23:07:33 T:140374689441536 NOTICE: Previous line repeats 6 times.
23:07:33 T:140374689441536 NOTICE: Thread LanguageInvoker start, auto delete: false
23:07:33 T:140374689441536 NOTICE: Previous line repeats 2 times.
23:07:33 T:140374689441536 NOTICE: -->Python Interpreter Initialized<--
23:07:33 T:140374194501376 NOTICE: -->Python Interpreter Initialized<--
23:07:33 T:140374211286784 NOTICE: -->Python Interpreter Initialized<--
23:07:35 T:140374194501376 NOTICE: Thread JobWorker start, auto delete: true
I just changed the title, since I broke it down that it is really caused by cpu1 running a 100%. Today I had the same blocking issue, even without any keyboard attached.

So the big question I have here is: Why does the IR remote stops working, when CPU1 is running at 100%?
Further more it is more interested to know, why CPU1 is even running at 100% in the first place?

Anyway for now I am reverting back to 12.2, because for me this is not usable anymore.
I have tried using the following from above:

modprobe ir-lirc-codec
ir-keytable -p LIRC

But that does not do anything. Does someone else have any idea how to analyze this issue any further?
Well, since it looks like I am on my own here Sad I will keep on typing what I am trying out, in the hope someone will pitch in, with their two cents Wink.

I now found this thread:

which says that I need to ditch LIRC at all.

First I tried this:
cat /proc/bus/input/devices

Here are my IR devices:

I: Bus=0019 Vendor=1050 Product=00c3 Version=0033
N: Name="Nuvoton w836x7hg Infrared Remote Transceiver"
P: Phys=nuvoton/cir0
S: Sysfs=/devices/pnp0/00:03/rc/rc0/input6
U: Uniq=
H: Handlers=kbd event4
B: EV=100013
B: KEY=fff 0 200108fc32e 237605100000000 0 700158000 419200004001 8e968000000000 10000000
B: MSC=10

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="MCE IR Keyboard/Mouse (nuvoton-cir)"
P: Phys=/input0
S: Sysfs=/devices/virtual/input/input7
U: Uniq=
H: Handlers=sysrq kbd mouse1 event5
B: EV=100017
B: KEY=30000 7 ff87207ac14057ff febeffdfffefffff fffffffffffffffe
B: REL=3
B: MSC=10

It looks like I am using Lirc, So will try to switch to Inputlirc:

[email protected]:~# ls -la /dev/lircd
lrwxrwxrwx 1 root root 15 May 23 2014 /dev/lircd -> /run/lirc/lircd

What we need are the values behind Phys=. In my case it is nuvoton/cir0

Now we write a new rules file for udev:

sudo nano /etc/udev/rules.d/10-irremote.rules

and put the following content in:


Now restart udev and trigger a new discovery:

sudo restart udev
sudo udevadm trigger

Under /dev/input should now be a symlink call irremote0:

ls /dev/input
First you have to install inputlirc and lirc. Please note that here we only need the lirc package because it contains "irw" and other utils.

sudo apt-get update
sudo apt-get install inputlirc lirc

Then you need to configure it properly:

sudo nano /etc/default/inputlirc

and put the following content in:

OPTIONS="-c -g -m 0"

The entries under EVENTS are the devices we created via udev. The OPTION entries mean the following:
-g Grabs the input from the devices, specified under EVENTS, so that no other application interferes with it.
-m 0 By default, all keycodes below 88 are filtered out. This setting ensures, that all keycodes are captured
-c Because some of the keys on the remote are mapped to keys with modifiers, this option maps this codes to single events.

Now restart inputlirc

sudo /etc/init.d/inputlirc restart

You can now test the remote via 'irw':

irw /dev/lircd

This is some sample output from irw when pressing buttons:

69 0 KEY_LEFT /dev/input/irremote0
69 0 KEY_LEFT /dev/input/irremote0
6c 0 KEY_DOWN /dev/input/irremote0
69 0 KEY_LEFT /dev/input/irremote0
69 0 KEY_LEFT /dev/input/irremote0
6a 0 KEY_RIGHT /dev/input/irremote0
160 0 KEY_OK /dev/input/irremote0
202 0 KEY_NUMERIC_2 /dev/input/irremote0
16d 0 KEY_EPG /dev/input/irremote0
e2 0 KEY_MEDIA /dev/input/irremote0
73 0 KEY_VOLUMEUP /dev/input/irremote0
73 0 KEY_VOLUMEUP /dev/input/irremote0

Note: You may see irremote0 instead of /dev/input/irremote0. If so, that is name inputlirc knows it as and is what you will need to put XBMC's Lircmap.xml instead of just irremote0.

Configuring XBMC

The last thing you need to do is let XBMC know to what buttons to respond. This is done by editing a LIRC Map for XBMC.

<As user XBMC>

nano -w ~/.xbmc/userdata/Lircmap.xml

and pasting in the following:

<remote device="/dev/input/irremote0">
Don't forget to make sure that in startup, lirc is no longer running, but Inputlirc instead.

nano -w /etc/rc.local

Add following (above exit 0).

service lirc stop
/etc/init.d/inputlirc restart

Also don't forget to update it from /etc/pm/sleep.d

nano /etc/pm/sleep.d

/etc/init.d/lirc stop
sudo /etc/init.d/inputlirc stop

/etc/init.d/lirc start
sudo /etc/init.d/inputlirc restart
Hai, thank you for this info.

This fixed my remote problem, but i only did the following.

sudo nano /etc/udev/rules.d/10-irremote.rules

sudo restart udev
sudo udevadm trigger

reboot, and my remote works ok.

for others...
ubuntu 14.04 kernel 3.15-rc6 on asrock E350/USB3, Xbmc Gotam. with the onboard CIR remote module.
no lirc configured, and no inputlirc used.

Big Thanks, so simple fix this one, im happy..