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...
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...
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:
Ich bin d.... . Habs gefunden.
Ach was, immerhin findest du doch alles: Fehler, Lösungen, Bugtracker...
Ich hatte jetzt gedacht, dass zu diesem Zeitpunkt irgendeine Änderung/Neuerung in 0.4 testing eingeflossen wäre und habe einen Zusammenhang mit diesem Posting gesehen, dass zeitlich auch etwa hinkommt.
Genau, damals wurde irgendwann zwischen yaVDR 0.4pre1 und pre2 vom Upstart-Job remoted (eventlircd war für Lirc-Empfänger deaktiviert) komplett auf eventlircd umgestellt. Damit LIrc-Empfänger trotzdem genutzt werden konnte, wurde (siehe yavdr 0.4: eventlircd und Fernbedienungen - Die Grundlagen) lircd mit --uinput gestartet, so dass ein virtuelles Eingabegerät unter /dev/input/ für den Lirc-Daemon erstellt wird, das dann über eine udev-Regel von eventlircd eingebunden wird.
Da darauf hin einige User Tastenprellen bemängelten, wurde der Repeat-Filter von eventlircd zusätzlich eingeschaltet, der laut dem original-Quellcode 900ms zwischen den ersten beiden Tastendrücken wartet. Dadurch war zwar das Prellen weg aber der VDR nur noch mehr schlecht als Rechte bedienbar (sehr langsame FB). Ich hatte dann angeregt den Repeatfilter so anzupassen (200ms Pause zwischen den ersten Tastendrücken, was sehr gut mit meiner Hauppauge A415 funktioniert hat), dass er einerseits das Prellen verhindert, andererseits aber eine flottere Bedienung des VDR möglich wird. Daraus entstand dieser Thread um das ganze zu testen und zu ermitteln was ein guter Standard-Wert wäre...
Etwas später habe ich dann lircd2uinput begonnen, weil ich genauer kontrollieren können wollte, wie eventlircd auf LIrc-Geräte reagiert.
wo wird die gesetzt, und seit wann ist das der Fall?
In der /etc/init/lircd.conf - aber wenn du die Option rausnimmst, brauchst du lircd2uinput (wie hier beschrieben: [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe ), damit die Tastendrücke an eventlricd weitergeleitet werden - oder du machst es wie CKone und stellst wieder auf das alte remoted um...
Was kann ich jetzt noch tun, damit mein yavdr 0.4 wieder so funktioniert, wie vor der Einführung von eventlircd?
Das Problem ist die --uinput Option von Lirc - da werden einfach zu viele Tastendrücke gesendet. Du könntest versuchen lircd2uinput zu installieren und entsprechend zu konfigurieren: [0.4]XBMC- Einfacher Tastendruck -> Doppelte eingabe
Bei dem Script hast Du schon sicherheitsbedenken?
Nein das Problem liegt darin:
Damit könnte jeder, der an eine Shell kommt beliebige Befehle hineinschreiben und durch den vdr ausführen lassen. Sowas sollte immer root gehören und nur von root beschreibbar sein.
Openelec enthält auch vdr-1.7.27 mit den Plugins, welche zum bauen eines Mediasytems
auf Basis von vdr nötig sind.
Schon klar, aber ohne echtes VDR-Frontend verpasst man das beste am VDR und kann auch fast zu TVheadend greifen.
BTW: wie macht sich das Deinterlacing bei den AMD-Grafikkarten? Kommt das an die Qualität von guten VDPAU-Grafikkarten heran?
oder sind aktuelle nur die testing repos online und für stable brauchts noch ne weile ?!
Ja so ist es.
unstable = Spielwiese für die yaVDR-Entwickler
testing = Pakete für die aktuellen beta1
stable kommt, wenn es einen stable Release für yaVDR 0.5 gibt...
Seit wann haben wir den stable-Quellen für precise? (Das ist eine Back to the future Doku ;))
EDIT : die policy wars nicht - weiter zur doku
D.h. das vdr-plugin-live und der vdr stammen aus unstable-vdr?
Die Abhängigkeiten des Pakets sind auch alle sauber installiert?
Es muss natürlich "apt-cache policy <Paketname>" heißen...
Außerdem fehlt dir das yavdr main ppa: https://launchpad.net/~yavdr/+archive/main - aber ich schreibe sowas ja nur in die Doku, damit es niemand liest http://www.yavdr.org/documentation/0.5/de/ch02s02.html
Ist da jetzt ein sudo davor?
Verstehe ich das richtig, dass tatsächlich eventlircd auch für serielle Empfänger läuft?
Ja, lircd wird mit der Option --uinput gestartet (was Probleme verusracht, da zu viele Tastendrücke an eventlircd gesendet werden). Daher gibt es von mir lircd2uinput, das als feiner regelbare Brücke zwischen lircd und eventlircd fungiert.
ZitatMit dem eventlircd für 0,3 habe ich es noch nicht probiert, aber lahmes Scrollen in Menüs will ich natürlich auch nicht haben. Das hat doch vorher mitr lircd alles einwandfrei funktioniert.
Wie gesagt die beste Lösung die ich für mich gefunden habe war lircd2uinput und das ist in yaVDR 0.5 eingeflossen - damit fliegt die FB wieder
Dann ist die Sache doch klar... da Fehlt die Berechtigung das zu tun.
Lösungsmöglichkeiten wären
Was steht im Skript? Hat der User vdr die nötigen Rechte das zu tun, was da ausgeführt werden soll?
IMHO hat sich das Problem mit yaVDR 0.5 und lircd2uinput weitgehend erledigt (und der Repeat-Filter von eventlircd ist standardmäßig deaktiviert) - zumindest haben bislang nur noch Leute mit lircd und dem KLS-Profil gemeckert - und es lies sich so lösen: (05) Gelöst - dank seahawk1986 - PwrOff bei Harmony-KLS1.6/doppelte Tastendrücke in XBMC
Hallo Dr. Seltsam und Cyberhogo, darf ich Fragen welches FB-Profil/FB ihr verwendet?
Es geht hier doch um den VDR und nicht nicht XBMC - und es gibt neben dem experimentellen PVR-Zweig von XBMC keine VDR-Frontends, die mit AMD-Grafikkarten sinnvoll hardwarebeschleunigt laufen würden...
Wie gesagt heisenbergus sollte sich genau überlegen was er haben will und danach seine Hardware und Software auswählen...
AFAIK geht es prinzipiell über VAAPI, aber die Qualität des Deinterlacings ist wohl sichtbar schlechter als bei VDPAU (es gitb hier im Forum einige Threads dazu, einfach mal suchen).
Außerdem solltest du dir überlegen was du an Software einsetzen willst - während VDPAU mit vielen VDR-Distributionen praktisch OOTB funktioniert, muss man für VAAPI eine Menge selbst konfigurieren, geeignete Treiber- und Software-Versionen auswählen und sich selbst darum kümmern, dass alles läuft.