No, there is no way to know if it's a TSOP4838 or something else. And somehow you did have the module manually loaded because it simply cannot work automatically. You must have forgot
Dont all GPIO receivers use lirc_rpi or do some use lirc_rp1? I could have simply forgotten that I added it to /etc/modules being it was originally on an alpha build upgraded to beta1.1 then beta2.
A note should be added to the wiki about GPIO receivers and loading the proper module with /etc/modules
Yes, all GPIO receivers use lirc_rpi. I created the additional lirc_rp1 module so you can have two different receivers connected as lirc sockets at once:
Code:
crw-rw---T 1 root video 248, 0 jan 1 1970 /dev/lirc0
crw-rw---T 1 root video 248, 1 jan 1 1970 /dev/lirc1
lrwxrwxrwx 1 root root 21 jan 1 1970 /dev/lircd -> ../var/run/lirc/lircd
In my case, lirc0 is the TSOP4838, lirc1 is my 433.92Mhz receiver.
The lirc_rpi and the lirc_rp1 are besides the names exactly the same.
(1st Aug, 2013 09:00 AM)CurlyMo Wrote: [ -> ]Yes, all GPIO receivers use lirc_rpi. I created the additional lirc_rp1 module so you can have two different receivers connected as lirc sockets at once:
Code:
crw-rw---T 1 root video 248, 0 jan 1 1970 /dev/lirc0
crw-rw---T 1 root video 248, 1 jan 1 1970 /dev/lirc1
lrwxrwxrwx 1 root root 21 jan 1 1970 /dev/lircd -> ../var/run/lirc/lircd
In my case, lirc0 is the TSOP4838, lirc1 is my 433.92Mhz receiver.
The lirc_rpi and the lirc_rp1 are besides the names exactly the same.
Clever.
I still wonder if I couldn't take a bit of the lirc_rpi driver code and create an application capable of recognizing an IR receiver from something else. Maybe when I get a free day or two I will try this, an lsgpio type application.
Just believe me, you can't and no-one can.
f1v4, can you test whether the tv off feature is working with you ? check /etc/default/xbmc config file for details.
From post #1
Quote:change /boot/cmdline.txt and update the snapshot name used to boot system. change "subvol=root/@" to "subvol=root/@beta2".
If I'm running on a USB drive and have removed subvol=root/@ previously from cmdline. what should I do?
a) move to next step?
b) add subvol=root/@beta2 to cmdline
c) ???
Kindest Regards
UPDATE: Never mind. Having reread the posts and finding cmdline.txt.backup I figured this out.
Rename cmdline.txt.backup to cmdline.txt. Change subvol=root/@" to "subvol=root/@beta2
(1st Aug, 2013 07:42 PM)mk01 Wrote: [ -> ]f1v4, can you test whether the tv off feature is working with you ? check /etc/default/xbmc config file for details.
I don't have an HDMI device.
(1st Aug, 2013 05:12 PM)CurlyMo Wrote: [ -> ]Just believe me, you can't and no-one can.
I will save myself the trouble and take your word on it.
(1st Aug, 2013 11:53 PM)Uncle_Tubbie Wrote: [ -> ]Quote:change /boot/cmdline.txt and update the snapshot name used to boot system. change "subvol=root/@" to "subvol=root/@beta2".
If I'm running on a USB drive and have removed subvol=root/@ previously from cmdline. what should I do?
a) move to next step?
b) add subvol=root/@beta2 to cmdline
c) ???
took me a while until I figured out what is going on, then realized the USB.
yes, if you copied from sd to usb and changed rootfsopts= and root= and you want to use the sd card for tests, yes, you have to rollback the original settings, reboot into SD card, THEN create the beta2 snapshot and change cmdline.txt to boot from @beta2 instead of @.
Has xbian-package-xbmc really been updated twice today?
yes. in the morning as final state for beta2 and now I finished making the xbian-packages able to install as supplement to any debian installation. I suppose with small mods it can run on ubuntu and other debian clones and if someone converts the debs to rpms, even on fedora.
xbian-update was updated as well, but there we keep version the same, so you would need to run apt-get clean and install —reinstall it. But makes no difference for you, changes were not related to update over Xbian version.
(I tested on stock minimal cd of Wheezy and Jessie).
i've tried , and except the btrf-tools version, thad i need to command the line like explain in previous post,
everything go right from a little tweak version of beta 1.1.
Since updating I have had xbmc crash twice while using plugins, I'm not home currently so can't post logs.
(2nd Aug, 2013 06:50 AM)f1vefour Wrote: [ -> ]Since updating I have had xbmc crash twice while using plugins, I'm not home currently so can't post logs.
the best way you can do is log into rpi as xbian, do "cd" - or be sure your pwd is /home/xbian, then right away start xbmc manually - run "/usr/local/lib/xbmc/xbmc.bin —standalone"
as soon as xbmc.bin crashes, it writes the error to std err, so you will see it. or check /var/log/upstart/xbmc.log. maybe will be there as well.
because bins / scripts have not been changed during day, i can only assume some of the added dependencies (99% libs) is causing that - ok so if it is related at all.
any specific add on to try for me?
(2nd Aug, 2013 06:43 AM)belese Wrote: [ -> ]i've tried , and except the btrf-tools version, thad i need to command the line like explain in previous post,
everything go right from a little tweak version of beta 1.1.
thanks belese for feedback. if possible, i would need to keep an eye on:
1) the tv off function with screensaver - if working ok, resuming working ok etc
2) configurations with wifi only (so eth0 not used)
and please, hour ago I removed module resize from config-xbmc package, python was logging some errors causing xbmc to crash with return code 143. as we are not using it, just deleted the parts, reinstalled, but already twice found some strange errors in xbmc.log regarding missing ")" somewhere in "Addon.versions…".
I'm not even sure it is related to this, it was the fresh Debian/Jessie install. So please just check the commit.
My initramfs got borked during the last update, I believe it may have been because I ran the upgrade as root instead of sudo.
I need a pointer on how to get xbian to boot back up?