die Fehlermeldung bleibt auch nach manueller Installation von python-uinput aus dem git bestehen
Umfrage zu Eventlircd - Einstellung des Repeat-Filters
- seahawk1986
- Closed
-
-
Warum musste man die denn nun unbedingt auch auf eventlircd umstellen?
Das musst du mit denen Diskutieren, die das eingeführt haben... Jetzt nach einem dreiviertel Jahr alles umzuwerfen ist ja auch blöd. IMHO ist es so aber super zum Testen der vorhandenen Fernbedienungen, da es prinzipiell egal ist wie viele Empfänger vorhanden sind). Außerdem hat man einen einheitlichen Weg den alle FB-Events nehmen, einen einheitlichen Namespace für die Tasten in VDR und XBMC und man kann sich einie Probleme im Zusammenhang mit den unterschiedlichen internen Repeat-Filtern von VDR und XBMC so zurechtbiegen wie man es haben will.lircd2uinput hat ja etliche Konfigurationsparameter. Ich befürchte, dass ich da am Ende auch wieder viele Experimente anstellen muss, bis das in Verbindung mit den in der lircd.conf zusätzlichen Parametern -die zum Teil das gleiche regeln- wie gewohnt läuft.
Also die Voreinstellung ist so, dass meine FB, die ich an Atric und yaUsbIr benutze da problemlos ohne zusätzliche Parameter funktionieren. Der Rest ist zum Spielen, z.B. weil meine Eltern gerne eine langsamere Reaktion auf Tastendrücke haben wollen als ich - oder weil es einige Profile gibt, die eine sehr lange Pause zwischen den gesendeten Signalen einlegen, was man dann auch sehr einfach kompensieren kann.Ich habe dann die hier genommen und hoffe, es ist die richtige.
Ja, die passt - in yaVDR 0.5 ist die Datei getemplated, weshalb sie da jetzt aus https://raw.github.com/yavdr/y…lircd2uinput.conf/10_main erstellt wird - danke für den Hinweis, dann passe ich das im anderen Thread an.File "/usr/bin/lircd2uinput", line 22, in <module>
import gobject
ImportError: No module named gobject
Ok, dann fehlt das Paket: -
Oh mann, was für ein Aufwand...
Nimm die yaVDR 0.5alpha1 wenn es daran scheitert - ansonsten habe ich mich damit glaube ich länger aufgehalten als die meisten anderen hier... -
ok, python-gobject habe ich installiert, jetzt kommt
Coderoot@ubuntuvdr1:/usr/local/src/python-uinput# lircd2uinput Traceback (most recent call last): File "/usr/bin/lircd2uinput", line 233, in <module> vlirc = main() File "/usr/bin/lircd2uinput", line 151, in __init__ self.Dbg.log('lircd_socket = %s'%(self.socket_path)) AttributeError: main instance has no attribute 'socket_path'
-
Dann läuft bei dir lircd nicht oder zumindest werden die nötigen Dateien von lircd nicht angelegt.
Das Skript sucht (wenn man den Socket nicht explizit mit "-s <pfad zum Socket>" übergibt) nach der /var/run/lirc/lircd.pid und öffnet dann eine Verbindung zu /var/run/lirc/lircd.<pid von lircd> -
ich habe es so gemacht wie in der Anleitung.
Nach "start eventlircd" habe ich den "status lircd2uinput" geprüft. Das ergibt "lircd2uinput stop/waiting".
wodurch wird lircd denn eigentlich gestartet?
-
Lircd sollte mit eventlircd mitgestartet werden (siehe /etc/init/lircd.conf "start on started eventlircd". lircd2uinput wird gestartet sobald lircd läuft (/etc/init/lircd2uinput.conf "start in started lircd").
Ist das ein lirc-serial Empfänger oder hängt der per USB am VDR? (dann würde der Start von lircd vermutlich über den lircd_helper laufen)
-
/var/run/lirc
Dann läuft bei dir lircd nicht oder zumindest werden die nötigen Dateien von lircd nicht angelegt.
Das Skript sucht (wenn man den Socket nicht explizit mit "-s <pfad zum Socket>" übergibt) nach der /var/run/lirc/lircd.pid und öffnet dann eine Verbindung zu /var/run/lirc/lircd.<pid von lircd>lircd läuft nach einem reboot, und auch die Dateien sind angelegt:
Quoteroot@ubuntuvdr1:/var/run/lirc# ls -l
insgesamt 4
srw-rw-rw- 1 root root 0 2012-06-26 13:41 lircd
srw-rw-rw- 1 root root 0 2012-06-26 13:41 lircd.928
-rw-r--r-- 1 root root 4 2012-06-26 13:41 lircd.pidTrotzdem:
root@ubuntuvdr1:/var/run/lirc# status lircd2uinput
lircd2uinput stop/waitingwenn ich allerdings llircd2uinput jetzt manuell aufrufe, kommt keine Fehlermeldung mehr, und auch die FB funktioniert am vdr.
Warum wird lircd2uinput jetzt nicht automatisch gestartet? -
Warum wird lircd2uinput jetzt nicht automatisch gestartet?
Es könnte sein, dass da der Pfad zu lircd2uinput in der /etc/init/lircd2uinput.conf nicht stimmt (das ".py" ist weggefallen) - so sollte es aussehen:
http://paste.ubuntu.com/1060615/ -
Code
Display More# Starts lircd2uinput daemon. description "LIRC2UINPUT" author "Alexander Grothe <alexandergrothe@gmx.net>" start on started lircd stop on stopping lircd respawn script while [ ! -e /var/run/lirc/lircd.pid ]; do sleep 1; done exec /usr/bin/python /usr/bin/lircd2uinput.py end script
Der Dateiname des Script ist aber doch lircd2uinput und nicht lircd2uinput.py!
Nachdem ich das ".py" in der conf entfernt habe, geht die FB jetzt nach einem reboot automatisch.Also passte die von mir gefundene conf doch nicht.
-
Es könnte sein, dass da der Pfad zu lircd2uinput in der /etc/init/lircd2uinput.conf nicht stimmt (das ".py" ist weggefallen) - so sollte es aussehen:
http://paste.ubuntu.com/1060615/zu spät
was hat es mit dem Zusatz in Klammern auf sich, der im template steht?
exec /usr/bin/python /usr/bin/lircd2uinput <?cs if:system.remote.lirc.option.repeat == "on" ?>-f<?cs /if ?> -
so wie die FB jetzt läuft, kann ich wunderbar damit leben. Ist vielleicht etwas träger als früher, aber zumindest keine Doppelausführung mehr. Mit den Optionen in /etc/init/lircd2uinput.conf werde ich heute Abend mal spielen.
Jetzt hoffe ich nur, dass all das, was ich da installiert habe, auch das nächste dist-upgrade überlebt...das betrifft ja /etc/init/lircd.conf und /etc/init/eventlircd.conf. Hast Du dazu noch einen Tip?
-
Wenn ich mich hätte durchsetzen können, dann würde yaVDR jetzt keine Lirc-Devices mehr unterstützen. Deshalb sei doch froh das es überhaupt noch geht. Was ich bisher lesen konnte, konnten bisher alle Lirc-User ihre Probleme mit den von Seahawk angebotenen Lösungen in den Griff kriegen. Lirc-Devices sind legacy und hoffentlich bald verschwunden.Gerald
was gibt es denn für Alternativen, die auch in Verbindung mit 2-3 Jahre alten Boards ein Einschalten aus dem standby erlauben? Oder meinst Du, ich soll den atric nur noch als Einschalter benutzen und einen zweiten IR-Empfänger für die Steuerung installieren?
-
was gibt es denn für Alternativen, die auch in Verbindung mit 2-3 Jahre alten Boards ein Einschalten aus dem standby erlauben? Oder meinst Du, ich soll den atric nur noch als Einschalter benutzen und einen zweiten IR-Empfänger für die Steuerung installieren?
yaUsbIR V2 LIRC USB IR Empfänger/Sender/EinschalterGerald
-
so wie die FB jetzt läuft, kann ich wunderbar damit leben. Ist vielleicht etwas träger als früher, aber zumindest keine Doppelausführung mehr.
Das ist die Kompromiss-Einstellung für XBMC - da VDR und XBMC unterschiedliche Repeatfilter haben, muss man da entweder eine gemeinsame Basis finden oder beim Start von XBMC die Parameter ändern (das wird dann aber noch komplexer...).Jetzt hoffe ich nur, dass all das, was ich da installiert habe, auch das nächste dist-upgrade überlebt...das betrifft ja /etc/init/lircd.conf und /etc/init/eventlircd.conf. Hast Du dazu noch einen Tip?
Im Prinzip könnte man ein angepasstes Template für die /etc/init/lircd.override erstellen sowie eine /etc/init/eventlircd.override - die override-Dateien überschreiben die normalen Upstart-Dateien entweder ganz oder auch nur einzelne Abschnitte (wie z.B. einen exec-Befehl oder den script Abschnitt) - genaueres steht in der Manpage zum "Override File Handling" von init: http://manpages.ubuntu.com/manpages/natty/man5/init.5.htmlwas gibt es denn für Alternativen, die auch in Verbindung mit 2-3 Jahre alten Boards ein Einschalten aus dem standby erlauben? Oder meinst Du, ich soll den atric nur noch als Einschalter benutzen und einen zweiten IR-Empfänger für die Steuerung installieren?
Zugegebenermaßen gefallen mit die echten Einschalter, die den Rechner auch aus dem S5 holen können vom Konzept her am besten - als Atric-Ersatz mit USB-Anschluss gibt es yaUsbIr (nicht von uns... yaUsbIr LIRC-fähiger USB IR Empfänger/Sender mit Einschalter) - der läuft allerdings auch über einen Lirc-Treiber. Ansonsten gibt es noch die iMon-Empfänger, die wohl auch als Einschalter fungieren können (da stört mich aber der Preis und der Steuerstick auf der Fernbedienung).Wenn es nur ein S3-Wakeup sein soll, geht das eigentlich mit den ganzen MCE-USB Empfängern - sofern das Board den USB-Wakeup sauber unterstützt.
-
Bisher wurden die meisten Treiber und Funktionen nach rc-core & Co portiert.
Die serielle Schnittstelle stirbt mehr und mehr aus.
Lirc ist nur einfach weil du es vor Jahren mal dich hineingekniet und verstanden hast.
Lirc ist unmaintained seit >1 Jahr bzw der momentane Maintainer treibt hauptsächlich rc-core nach vorne.
rc-core ist eine Übersetzung des Lirc auf das Input Framework/Kerneltreiber
Das Lirc protokoll wäre vermutl. längst tot wenn Xorg alle Tasten des Inputframeworks unterstützen würde und nicht nur einen Satz von 255 Tasten.- Lirc hatte Probleme wenn der Daemon vor der Hardware gestartet ist
- Lirc hat probleme gemacht wenn es nach dem VDR gestartet ist
- Jede Belegung/jedes Gerät hat irgendwie sein eigenen Budenzauber veranstaltet.- Eventlircd startet ohne jedes Gerät und stellt einen LIRC Socket bereit
- Die Geräte kommen und gehen wie sie wollen und eventlircd gibt sie als EIN Gerät für die Anwendungen aus.
- auch wir lernen wenn unsere Theorien auf die Praxis treffen.Meine These ist: Es ist nicht wirklich kompliziert wenn man sich mal reindenkt. Am Ende musst du dich um bestimmte Sachen nicht mehr kümmern und sie funktionieren einfach, die man sich sonst nie geschafft hätte sie zu konfigurieren.
-
was gibt es denn für Alternativen, die auch in Verbindung mit 2-3 Jahre alten Boards ein Einschalten aus dem standby erlauben? Oder meinst Du, ich soll den atric nur noch als Einschalter benutzen und einen zweiten IR-Empfänger für die Steuerung installieren?
Das Beste ist tatsächlich du behältst deinen Atric zum Einschalten und einen MCE-USB als Empfänger. Das funktioniert sofort ootb.Gerald
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!