Forum

Full Version: Remote not working since yesterday's upgrade
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi everybody, my first post here Smile

I've been using xbian for quite a while now and never had troubles with it and really love it.

Until today ;(.

I ran the update through the xbmc's interface > settings > xbian > update, restarted my raspberry pi correctly.

Looks like everything is working, except my remote.

Actually, my remote is recognized, but only has the 4 arrows working (up, down, left, right) and nothing else. So, I imediatly though about my Lircmap.xml that I set up during the installation process one year ago but this one looks unchanged.

Then, I tryied few things :

When I do:

Code:
sudo /etc/init.d/lirc start
here is the output
Code:
/etc/init.d/lirc: 54: [: 0: unexpected operator
/etc/init.d/lirc: 56: [: 0: unexpected operator
/etc/init.d/lirc: 58: [: 0: unexpected operator
[ ok ] Loading LIRC modules:.
[ ok ] Starting remote control daemon(s) : LIRC :

The service seems to start properly, but I have a "unexpected operator" error (don't know if it affects for my problem)

Also, the weird thing is that my remote still works even if the lirc service is stopped

Code:
sudo /etc/init.d/lirc stop
/etc/init.d/lirc: 54: [: 0: unexpected operator
/etc/init.d/lirc: 56: [: 0: unexpected operator
/etc/init.d/lirc: 58: [: 0: unexpected operator
[ ok ] Stopping remote control daemon(s): LIRC:.

After that, I can still use my remote, but only the up, down, left, right buttons are working.

For info, I am running XBian 1.0a4 with a Microsoft MCE remote and a USB InfraRed transmitter.

- Did this update introduced a new way to configure remotes instead of the Lircmap.xml?
- Is that normal if my remote is recognized even if the lirc service is down?
- How can I setup the other buttons of my remote?

Thanks in advance for your help and all my greatings the the Xbian team for that wonderful distribution.
Hello,
Since the last update i have the same problem. I'm using a Microsoft MCE remote and a USB InfraRed transmitter too. Only arrow keys seem to work
I've got the same problem as the users above, with my mceusb remote only recognising the cursor keys -- from the console they're seen as the usual cursor escape sequences.

I've been running 1.0a5 and later nightly releases without any problems, and the trouble only started when I upgraded to 1.0 beta 1.1 this evening. I was also getting the same /etc/init.d/lirc shell errors as above, though I tried manually setting some values in /etc/lirc/hardware/custom.conf to clear them up. I haven't managed to improve the remote functionality though.

To check, I've just done a clean install of 1.0 beta 1.1, and unfortunately the remote has the same problem. The only clue I have so far is that 1.0a5 actually handled the device as 'linux-input-layer', and maybe the new version is trying to use the proper 'mceusb'.

I had a quick poke at it using 'irw', and it's giving output for some other keys, though not essential ones like the OK button. It's been a while since I've done any lirc diagnostics so I'd appreciate further suggestions on diagnosing this Smile
(29th Jun, 2013 08:41 PM)manslipkorn Wrote: [ -> ]I ran the update through the xbmc's interface > settings > xbian > update, restarted my raspberry pi correctly.

Code:
sudo /etc/init.d/lirc start
here is the output
Code:
/etc/init.d/lirc: 54: [: 0: unexpected operator
/etc/init.d/lirc: 56: [: 0: unexpected operator
/etc/init.d/lirc: 58: [: 0: unexpected operator
[ ok ] Loading LIRC modules:.
[ ok ] Starting remote control daemon(s) : LIRC :

the "upgrade" through xbian-config (and I suppose xbmc-config as well) was quite broken in alpha5 and reported many times on github. that's why the upgrade instructions were solely per terminal access and command line.

I'm looking at lirc script in /etc/init.d and on lines 54, 56 an 58 is no logical statement, what means, your lirc script is definitely not the one as it should be.

login via ssh and do "apt-cache policy xbian-package-lirc". my returns
Code:
root@xbian:~# apt-cache policy xbian-package-lirc
xbian-package-lirc:
  Installed: 1.4-3
  Candidate: 1.4-3

md5sum of /etc/init.d/lirc is
Code:
root@xbian:~# md5sum /etc/init.d/lirc
c76162eaa9ba1e35ce4c675d7dcbc93f  /etc/init.d/lirc
After the update to 1.1 I have the same problems:

root@xbian:/home/xbian# apt-cache policy xbian-package-lirc
xbian-package-lirc:
Geïnstalleerd: 1.4-3
Kandidaat: 1.4-3
Versietabel:
*** 1.4-3 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages 100 /var/lib/dpkg/status
1.4 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages
1.3 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages

root@xbian:/home/xbian# md5sum /etc/init.d/lirc
c76162eaa9ba1e35ce4c675d7dcbc93f /etc/init.d/lirc
(16th Jul, 2013 11:05 PM)JeHaLi Wrote: [ -> ]After the update to 1.1 I have the same problems:

root@xbian:/home/xbian# apt-cache policy xbian-package-lirc
xbian-package-lirc:
Geïnstalleerd: 1.4-3
Kandidaat: 1.4-3
Versietabel:
*** 1.4-3 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages 100 /var/lib/dpkg/status
1.4 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages
1.3 0
500 mirror://apt.xbian.org/mirror.txt/ wheezy/main armhf Packages

root@xbian:/home/xbian# md5sum /etc/init.d/lirc
c76162eaa9ba1e35ce4c675d7dcbc93f /etc/init.d/lirc

jehali, it can't be the exactly the same, because on those lines there is no if [] nor "test -"

maybe the reason is the same, but output must be in details different (+- another line reports error). post it, then I can look into script, the exact line and discuss possible reasons.

btw: which one module is the lirc loading? after it starts check "lsmod" in terminal. many lirc or mseusb modules got into kernel now, can be, that something is auto loaded and dis-functioning the working config. hard to say. the original patches to provide lirc modules are still the same and present for all xbian kernels.

if you have running oldies like alpha4, check the lsmod there and on beta1.1 . and let's discuss then.

what about this info?

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6821

all the keymaps are available in package ir-keytable (apt-get install ir-keytable)
Hi, I'm getting the same problem, was going to subscribe to this forum topic so I can check when I get home this afternoon but get following error message so this is purely so I can get a notification of replys!

Code:
Authorization code mismatch. Are you accessing this function correctly? Please go back and try again.
i have the exact same problem...
still looking for a solution
This is the same problem as in the thread "MS RC6 Remote help".
Maybe can someone give us a clue to solve this problem??
I've tracked down the source of the syntax error to hardware.conf, which was changed to cache the contents of /proc/bus/input/devices in a variable. I've created a pull request for the fix here: https://github.com/xbianonpi/xbian/pull/434

I did this from work in my lunch hour, so I don't know if it's a fix for the overall issue yet. It will mean it picks up the correct eventN device now, so I'm hopeful.
After the patch, it does now pick up the correct device, and irw shows the expected key presses.

However, even after a reboot, I still need to manually restart the xbmc service for most of the remote keys to be picked up. Restarting just lircd didn't seem to help. Could lircd be starting to late for xbmc to use on the initial boot? Can anyone suggest where to look next?

In the short term I still have a work-around that passes the WAF test Smile
(30th Jul, 2013 02:50 AM)obo Wrote: [ -> ]After the patch, it does now pick up the correct device, and irw shows the expected key presses.

However, even after a reboot, I still need to manually restart the xbmc service for most of the remote keys to be picked up. Restarting just lircd didn't seem to help. Could lircd be starting to late for xbmc to use on the initial boot? Can anyone suggest where to look next?

In the short term I still have a work-around that passes the WAF test Smile

Same thing here. Remote works great but only after a manual restart of XBMC service.
Reference URL's