Forum

(31st Jul, 2013 11:57 PM)f1vefour Wrote: [ -> ]@mk01

After upgrading today there are a couple of issues.

1. XBMC does not start on its own, must run 'start xbmc'

2. /etc/lircd.conf is moved to /etc/lircd.conf.xbian semi-breaking lircd if configured according to the wiki.

3. There is no lircd service to stop/start even though it does start on boot.

4. The lirc_rpi module is not loading upon bootup, must manually 'modprobe lirc_rpi'

So to get back to where I was I had to move lircd.conf.xbian to lircd.conf, modprobe lirc_rpi and finally start xbmc.

1) can you do wget http://ivka57.dyndns-ip.com/a.sh, run the script and send me created tar.gz file in /tmp to my email?
2) Koenn merged a fix to some issues (not very well known to me) into lirc package which needed to rewrite etc/lirc/hardware.conf... do you anyhow mean /etc/lirc/*.conf files ? So .conf files were renamed to .xbian and new not installed ? or just your custom config was renamed and you have to rename it back?
3) lircd is "lirc" and still as sysvinit script located at /etc/init.d . It is started as part of /etc/rc2.d in runlevel 2.
4) there are 8 different lirc modules, from brief look into the startup script, the right one should be defined in /etc/lirc/hardware.conf . I have 0 experience in running this as not used there, so feel free to describe in more detail how you was used to use this/configure and update in the past. lirc package is one of two, where no sctructural changes have been made since alpha5. at least this is how I remember it.

or you run the debian's stick lirc package? for this there is "conflict:" set, which can cause uninstall of stock lirc support and reinstall it by xbians. but then let's not install xbian-package-lirc at all. was there strict dependency to it somewhere? i will check the other packages.

---

what is content of /etc/xbian_revision please ?

---

ok, there is dependency in xbian-update to pre-depend on xbian-package-lirc, but it has been there since beta1. if this is case of using stock lirc support, then we have to change it from pre-depend to breaks, in this way it would be just upgraded in case it is already installed, but will not reinstall stock support if used.

I started with stock beta1.1 from image upgraded to beta2 through method in OP days ago, today I pulled in your recent changes.

My /etc/xbian_version is Beta1.1

Before I ran apt-get update/upgrade today I did not have to modprobe the lirc_rpi module, not on Beta1.1 or Beta2...now the module is not auto loading after todays update.

I am running the xbian lirc package.

The wiki tells you to add your configuration to /etc/lirc/lircd.conf, but the new lirc package today overwrote this file backing up the original to /etc/lirc/lircd.conf.xbian.

I PM'd you a link to my configuration as I don't know your email address.

ok, I'm sending this info about lirc to Koen. but probably in your old conf file was the module specified, in the new default is not, but new has to be used to fix bug with microsoft RC6 or MS6 or something similar. ok, this conflict has to be solved somehow, or at least documented. let's wait for Koen's addition to the topic.

thanks for the files, I reviewed them already and posted feedback back to you.

---

btw: my email is on user card here on forum, on git as public as well

No problem, I could have just rolled back thanks to the new snapshot system now in place (what an awesome feature this is). I want to help get these issues resolved so we can have a shiny new beta :-)

I am using Tapatalk so I couldn't see the email on your profile.

I hope you don't mind, can be usefull for others as well

mk01 Wrote:

f1vefour Wrote:I just checked, there are four packages being held back. Should these be force upgraded?

force should not be needed, they are held back probably due some new dependency - meaning updating them would install other packages.

just copy&paste the package names to "apt-get install ...."

PM awaiting you.

Packages held back:

xbian-package-initramfs-tools xbian-package-kernel xbian-package-splash xbian-update

as I wrote one msg before, just do

apt-get install xbian-package-initramfs-tools xbian-package-kernel xbian-package-splash xbian-update

New packages to be installed:

rng-tools xbian-package-upstart-xbmc-bridge

xbian-package-initramfs-tools xbian-package-kernel xbian-package-splash xbian-update

Installing now, will edit post and let you know after a reboot how it went.

*edit1*
Hardware rng failed to start (expected since no hardware rng).

Installation was successful, RPi powered off instead of rebooted (unplug/replug) and booted into XBMC successfully.

I once again had to manually run 'modprobe lirc_rpi' and then my remote works.

I will re-edit to see if external devices are picked up by XBMC now.

*edit2*
External devices are indeed mounting and available in XBMC (even a btrfs formatted drive!).

Way to go mk01, Koenkk and the rest of the Xbian team. You guys are an excellent group!

perfect. thanks.

---

Quote:*edit1*
Hardware rng failed to start (expected since no hardware rng).

if this happened during install (prior to reboot), means no error

can you send me the original lirc.conf files which worked ?

---

anyhow, RPI has hw random generator and in the 1.3-3 kernel package module is included.

check /etc/default/xbian-rng settings (to choose from frandom / hwrng)

(1st Aug, 2013 02:29 AM)mk01 Wrote: [ -> ]perfect. thanks.

---

Quote:*edit1*
Hardware rng failed to start (expected since no hardware rng).

if this happened during install (prior to reboot), means no error

can you send me the original lirc.conf files which worked ?

---

anyhow, RPI has hw random generator and in the 1.3-3 kernel package module is included.

check /etc/default/xbian-rng settings (to choose from frandom / hwrng)

I didnt know the RPi had a hardware rng, it happened during install (frandom is working upon reboot). No issue.

The lircd.conf isn't relative to the lirc_rpi module, I'm uncertain how the module was previously being inserted but the lircd.conf only contains links to configuration files (outside of what I added).

I could add the lirc_rpi module to /etc/modules to have it autoload, I'm assuming an lirc script should do this but isn't.

the main script is choosing lirc_rpi config file (with specified module defined inside) based on "dmesg" output and presence of loaded lirc_rpi module. chicken-egg.

can you please send dmesg and lsusb -v outputs with IR connected and disconnected?

I checked alpha5 image and there are no lirc modules. assuming the support was compiled in kernel, making the above logic work.

still, udev should trigger the device and module load. send the outputs please.

---

this

is result of your manual modprobe or ins mod action?

(1st Aug, 2013 05:10 AM)mk01 Wrote: [ -> ]

Code:

init: xbmc post-start process (1082) terminated with status 1
init: xbmc main process (1081) killed by TERM signal
lirc_dev: IR Remote Control driver registered, major 248
lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
lirc_rpi lirc_rpi.0: lirc_dev: driver lirc_rpi registered at minor = 0
lirc_rpi: driver registered!
lirc_rpi: auto-detected active low receiver on GPIO pin 18
init: xbmc post-start process (1322) terminated with status 1

is result of your manual modprobe or ins mod action?

This is from my manual modprobe.

My IR receiver is not USB but GPIO connected.

again no real experience there, but CurlyMo has. What happens, if you load the gpio support first?

modprobe i2c_bcm2708 and spi_bcm2708 ?

There is no way to check if a user has a GPIO receiver connected. This means that Lirc will only pick the right hardware.conf if the module was manually loaded before lirc is start. This can't be automated. So, indeed, add lirc_rpi to your /etc/modules and make sure the module is loaded before lirc starts. Here it is (beta 1.1).

(1st Aug, 2013 07:34 AM)CurlyMo Wrote: [ -> ]There is no way to check if a user has a GPIO receiver connected. This means that Lirc will only pick the right hardware.conf if the module was manually loaded before lirc is start. This can't be automated. So, indeed, add lirc_rpi to your /etc/modules and make sure the module is loaded before lirc starts. Here it is (beta 1.1).

I didn't previously have to add lirc_rpi to /etc/modules so what changed?

No worries, I will add module manually.

Seems you could poll pin 18 on GPIO to see if a receiver is connected with a simple targeted C application.