[RichG]

Just the TVHeadend issue.

I'll repeat the dmesg if the remote fails after a reboot ... (will try now).

[f1vefour]

Just the TVHeadend issue.

I'll repeat the dmesg if the remote fails after a reboot ... (will try now).

Thanks, I'm not at home but I can post the messages when I get there. It happens regularly, and my experience mirrors yours. Sometimes it doesn't work at all and other times it is intermittent.

[RichG]

OK - just did a cold start and remote wasn't working.

dmesg shows:

Code:

OpenELEC:~ # dmesg | grep lirc
[   15.419135] lirc_dev: IR Remote Control driver registered, major 249
[   15.436948] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[   16.346286] lirc_rpi: auto-detected active low receiver on GPIO pin 18
[   16.346721] lirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0
[   16.346736] lirc_rpi: driver registered!
[   16.515994] input: lircd as /devices/virtual/input/input2

Which looks the same as before (when the remote did work). I think this rules out kernel problem (but I have little knowledge on these things).

[bonzinip]

It's not an OE issue it's the lirc_rpi kernel module, check dmesg when it happens and you should see some debugging messages about lirc_rpi. I believe the lirc_rpi module code needs some messaging to make it more compatible with newer kernel revisions.

I'm not using these builds, I'm using Raspbmc, but I also have IR problems and I don't think it's lirc_rpi. I only see problems with the numeric keys (but not just in live TV mode), and it works in an XBMC build from one month ago (same kernel, same firmware), so it's unlikely to be a kernel problem.

[RichG]

It's not an OE issue it's the lirc_rpi kernel module, check dmesg when it happens and you should see some debugging messages about lirc_rpi. I believe the lirc_rpi module code needs some messaging to make it more compatible with newer kernel revisions.

I'm not using these builds, I'm using Raspbmc, but I also have IR problems and I don't think it's lirc_rpi. I only see problems with the numeric keys (but not just in live TV mode), and it works in an XBMC build from one month ago (same kernel, same firmware), so it's unlikely to be a kernel problem.

Yeah, I checked a week or so ago using current firmware and an old version of OE (I think a December Gotham build) and that worked fine.

That is interesting that you have issues in Rasbmc too, although they may not necessarily be related. It does show that something has become a little broken somewhere, most probably with XBMC itself.

[f1vefour]

OK - just did a cold start and remote wasn't working.

dmesg shows:

Code:

OpenELEC:~ # dmesg | grep lirc
[   15.419135] lirc_dev: IR Remote Control driver registered, major 249
[   15.436948] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[   16.346286] lirc_rpi: auto-detected active low receiver on GPIO pin 18
[   16.346721] lirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0
[   16.346736] lirc_rpi: driver registered!
[   16.515994] input: lircd as /devices/virtual/input/input2

Which looks the same as before (when the remote did work). I think this rules out kernel problem (but I have little knowledge on these things).

It's strange that our issue is identical yet you don't show the debugging. It certainly isn't an XBMC issue, perhaps a lircd problem.

[RichG]

It's strange that our issue is identical yet you don't show the debugging. It certainly isn't an XBMC issue, perhaps a lircd problem.

It's all very strange...

lircd is part of the kernel / firmware is it not? So using latest kernel with old XBMC you would expect to see that same problem, but this is not the case (at least for me).

I am wondering if it might be a timing issue. As in, if XBMC starts before lircd is ready it will fail. Perhaps this is why I see overclocking having an impact?

Is there possibly a way to delay the start of XBMC on reboot to give lircd more time?

[f1vefour]

lircd is a binary, the daemon that translates the key presses to actions

---

I am wondering if it might be a timing issue. As in, if XBMC starts before lircd is ready it will fail. Perhaps this is why I see overclocking having an impact?

Is there possibly a way to delay the start of XBMC on reboot to give lircd more time?

To test this boot up and if the remote isn't functional kill xbmc and let it restart itself, if the remote then functions it is a timing issue.

[RichG]

lircd is a binary, the daemon that translates the key presses to actions

Yes - but does it get updated with the kernel? ie If I keep a recent kernel but go back to older system is lircd recent or older?

[f1vefour]

lircd is a binary, the daemon that translates the key presses to actions

Yes - but does it get updated with the kernel? ie If I keep a recent kernel but go back to older system is lircd recent or older?

It doesn't get updated with the kernel.

[RichG]

To test this boot up and if the remote isn't functional kill xbmc and let it restart itself, if the remote then functions it is a timing issue.

Ah yes - good point. This has been just as intermittent for me. Sometime it works, other times not.

---

lircd is a binary, the daemon that translates the key presses to actions

Yes - but does it get updated with the kernel? ie If I keep a recent kernel but go back to older system is lircd recent or older?

It doesn't get updated with the kernel.

So, as I said, it works with new kernel / lircd and old system / XBMC, but is problematic with newer system / XBMC. Suggests it's not related to any update that has occurred to lircd / kernel.

[tfouto]

to me, gpio didn't work either with latest gotham nightlies. Only worked after installed this addon:

http://openelec.tv/forum/124-raspberry-p...=270#97620

Thanks for your hard work...

[RichG]

to me, gpio didn't work either with latest gotham nightlies. Only worked after installed this addon:

http://openelec.tv/forum/124-raspberry-p...=270#97620

Thanks for your hard work...

I was using the add-on and it worked well for a while, but at some point it stopped working (and actually made matters worse) so I disabled it.

Looking at the python script it appears to do something similar to what I have in my autostart.sh script, but not quite the same:

Code:

OpenELEC:~ # cat /storage/.config/autostart.sh
#!/bin/bash
modprobe lirc_rpi
eventlircd --evmap=/etc/eventlircd.d --socket=/var/run/lirc/lircd --release=_UP
/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

Code:

OpenELEC:~ # cat /storage/.xbmc/addons/script.service.lirc_rpi_launcher/addon.py
#!/usr/bin/env python
import os
import xbmc
import xbmcaddon

__addon__       = xbmcaddon.Addon(id='script.service.lirc_rpi_launcher')
__addonname__   = __addon__.getAddonInfo('name')
__icon__        = __addon__.getAddonInfo('icon')

title = "Lirc_RPi Launcher"
text1 = "Initialising"
text2 = "Initialised"
time = 5000  # ms

cmd_mod_rpi = "modprobe lirc_rpi"

cmd_kill_lircd = "killall lircd; sleep 4; killall lircd;" # give modprobe time to finish

cmd_lircd = "/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"

xbmc.executebuiltin('Notification(%s, %s, %d, %s)'%(title, text1, time, __icon__))

os.system(cmd_mod_rpi)
os.system(cmd_kill_lircd)
os.system(cmd_lircd)

xbmc.executebuiltin('Notification(%s, %s, %d, %s)'%(title, text2, time, __icon__))
OpenELEC:~ #

[corb06]

If in playback video setting I enable "sync video to display" (with any of the sub-options) crackling is still audible, as soon as i disable this option crakling goes away.

Aha, that is interesting. I've been trying to spot the crackling, but haven't heard it, but I don't have that option enabled.

As a recommendation, I would suggest enabling "Adjust display refresh to match video", but disabling "sync video to display".

"Sync video to display" makes the video clock the master, and audio will get resampled (for non-passthrough) or dropped/duplicated for passthrough to fit in.
This can cause a slight degradation in audio quality, so shouldn't be enabled as standard unless you are having a specific problem.

The crackling however shouldn't be happening, and that should be fixable (I can imagine a reason for it now you've pointed out exactly when it occurs).

Thanks!

Now the crackleing sound distortion is gone, so unticking Sync Video did the trick.

[bonzinip]

It's strange that our issue is identical yet you don't show the debugging. It certainly isn't an XBMC issue, perhaps a lircd problem.

For me the problem was simply that XBMC stopped recognizing KEY_0 to KEY_9 (as opposed to KEY_NUMERIC_0 to KEY_NUMERIC_9). Caused by pull request #4001. Pull request #4000 should fix it.