2014-02-16, 22:21
Just the TVHeadend issue.
I'll repeat the dmesg if the remote fails after a reboot ... (will try now).
I'll repeat the dmesg if the remote fails after a reboot ... (will try now).
(2014-02-16, 22:21)RichG Wrote: Just the TVHeadend issue.
I'll repeat the dmesg if the remote fails after a reboot ... (will try now).
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
(2014-02-16, 22:18)RichG Wrote: 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.
(2014-02-16, 22:42)bonzinip Wrote:(2014-02-16, 22:18)RichG Wrote: 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.
(2014-02-16, 22:31)RichG Wrote: 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).
(2014-02-16, 22:51)f1vefour Wrote: 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.
(2014-02-16, 22:59)RichG Wrote: 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?
(2014-02-16, 23:04)RichG Wrote:(2014-02-16, 23:00)f1vefour Wrote: 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?
(2014-02-16, 23:00)f1vefour Wrote: 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.
(2014-02-16, 23:04)f1vefour Wrote:(2014-02-16, 23:04)RichG Wrote:(2014-02-16, 23:00)f1vefour Wrote: 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.
(2014-02-16, 23:25)tfouto Wrote: 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...
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
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:~ #
(2014-02-16, 18:52)popcornmix Wrote:(2014-02-16, 18:37)mcarni Wrote: 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).
(2014-02-16, 22:51)f1vefour Wrote: 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.