Beiträge von seahawk1986

    gerade gefunden das xrandr das anzeigen kann, leider bei mir immer 'connected' auch wenn der TV aus ist

    Das kann auch einfach daran liegen, dass die verbundenen Bildschirme und deren EDID statisch in der /etc/X11/xorg.conf(.yavdr) hinterlegt sind - das ist bei yaVDR sogelöst, damit der X-Server auch dann sauber starten kann, wenn angeschlossene Receiver/TVs/Monitore abgeschaltet sind bzw. aus anderen Gründen nicht als verbunden erkannt werden würden).

    Ich vermute, dass man da am ehesten über CEC (oder falls verfügbar über ein serielles- oder Netzwerk-Interface von TV bzw. Receiver) abfragen könnte, ob der TV an ist.

    Was denn?

    Es bietet über DBus die Möglichkeit im laufenden Betrieb lirc-kompatible Sockel hinzuzufügen bzw. zu entfernen (und man kann auch Tastendrücke auslösen).


    Die Grundidee ist, dass man ein beliebiges Systemd-Skript leicht für lircd2uinput fit machen kann - z.B. gibt es dann zusätzlich zu einer lircd.service, die aus dem originalen Paket stammt, ein kleines Drop-In, das den Sockel bei lircd2uinput an- bzw. abmeldet:

    Code
    1. # /etc/systemd/system/lircd.service.d/lircd2uinput.conf
    2. [Service]
    3. ExecStartPost=/usr/bin/lircd2uinput-add /var/run/lirc/lircd0
    4. ExecStopPost=/usr/bin/lircd2uinput-remove /var/run/lirc/lircd0

    Fürlircd2uinput braucht man etliche Python Pakete oder man baut mitpyinstaller ein Binary, dass aber lächerlich groß wird. Das ist fürein Minimal-System wie LibreELEC nicht so schön.

    Schön, wenn du dir die Zeit nimmst da etwas schlankes in C zu bauen - vielleicht könnte man das dann auch dem neuen Lirc-Maintainer vorschlagen (nur wäre da ein funktionierender Key-Release notwendig, denn es muss ja nicht zwingend eventlircd dran hängen).


    lircd2uinput kann ja noch ein paar Sachen mehr als nur Tastendrücke von einem einzigen Lircd-Sockel weiterzuleiten, daher ist das für yaVDR schon ok - zumal bis auf python3-uinput alle Abhängigkeiten auch von anderen Sachen wie dem Frontend-Skript genutzt werden.

    Das kenne ich nur, wenn der USBDP Pullup nicht den vorgeschriebenen Wert hat. Bei China-Ware gibt es das manchmal. Hast du einen Blauen? Dann messe ich mal.

    Ja, das ist ein blaues USBASP V2.0 - welche Werte für die Widerstände sollte ich da messen können? Die SMD-Bauteile scheinen z.T. etwas wenig Lötzinn abbekommen zu haben (eventuell ist es ein Wackelkontakt, an dem Athlon64 fliegt der Empfänger bei längerem Betrieb immer mal wieder kurzzeitig raus und wird danach wieder neu erkannt):



    Der Hauptknackpunkt ist für mich als Erstes die Frage, wieso ich mit evtest an /dev/input/eventX nach einem Key-Down fortlaufend Wiederholungen sehe, bis ein Key-Up kommt (so wie bei Keyboard Tastendrücken), während du keine zusätzlichen Tastendrücke hast.

    Um was für einem Gerät geht es da genau? lircd2uinput sollte eigentlich nur Tastendrücke weiterreichen, die es von einem Lirc-kompatiblen Sockel liest (Ausnahme ist der Key-Release, der bei der Version, die aktuell in yavdr-utils steckt, auch über einen Timeout ausgelöst werden kann, sonst passiert das z.B. wenn man auf eine andere Taste wechselt). Bei anderen Varianten um die Tasten-Events zu generieren (wie z.B. lircd-uinput) kann das natürlich abweichen. Die lircd2uinput-Version im weiter oben verlinkten Git-Repository ist noch mal deutlich besser darin eventlircd dazu zu bringen möglichst 1:1 das auf dem Eventlircd-Sockel auszugeben, was auf dem lirc-kompatiblen Sockel ankommt - der IRMP-Empfänger hat wohl die Besonderheit, dass er die ersten gesendeten Tastenwiederholungen ignoriert und mit früheren Versionen läuft lircd2uinput deswegen leicht mal in den Timeout und liefert deswegen erst einen einzelnen Tastendruck und erst danach Tastenwiederholungen für eine gedrückt gehaltene Taste.

    Mit der udev Regel aus meinem git schon immer.

    Wenn ich das richtig sehe, sorgt diese Udev-Regel im Zusammen spielt mit der implircd.service nur dafür, dass irmplircd bei erkannter Hardware gestartet wird. Und erst dann wird der lirc-kompatible Sockel bereitgestellt. Damit fängt man sich eine implizite Abhängigkeit von KODI zu irmplircd ein, denn wenn der Sockel noch nicht verfügbar ist, wenn KODI gestartet wird, reagiert es nicht auf die Fernbedienung (im Gegensatz zum VDR macht KODI keine endlosen Verbindungsversuche). Eventlircd hat keinerlei Abhängigkeiten zu vorhandener Hardware und bindet alles dynamisch ein, was ein passendes udev-Attribut trägt.

    Nach dem ersten Start von epgd in der neuen Version solltest du im Log sehen, dass er die Datenbank für die neue API anpasst - bei mir sah das im Log so aus:

    Code
    1. Jan 01 11:57:50 ikarus epgd[409]: Migration of table 'recordinglist' from version <= 4 ...
    2. Jan 01 11:58:17 ikarus epgd[409]: ... done

    eventlircd produziert eigentlich nur auf Key-Down bzw. Key-Repeat Events hin Tastendrücke auf seinem Sockel, eine automatische Tastenwiederholung gibt es nicht. Wenn eine Taste von lircd2uinput länger als nötig gedrückt gehalten (also nach einem Tastendruck nicht Zeitnah ein Key-Up gesendet) wird, sollte das keine zusätzlichen Tastendrücke verursachen.


    Ich habe lircd2uinput für kommende yaVDR-Versionen mal so überarbeitet, dass es sich da möglichst transparent verhält, statt wie bisher zu versuchen überflüssige Wiederholungen herauszufiltern: https://github.com/seahawk1986/lircd2uinput (der letzte Stand ist noch nicht in den PPAs für xenial und bionic - Launchpad baut seit heute Morgen angeblich wieder Pakete, aber es wird vermutlich noch Stunden oder Tage dauern, bis alle aufgelaufenen Aufträge abgearbeitet sind). Damit sollte abgesehen von einer kleinen zusätzlichen Latzenz von ca. 2 ms durch den Umweg über lircd2uinput und eventlircd (gemessen mit einem modifizierten irw (irw.zip), das einen Timestamp für jeden Tastendruck mit ausgibt) kein spürbarer Unterschied mehr zu einem nativen lircd-kompatiblen Daemon bestehen.


    Vielleicht kannst du mal ausprobieren, ob das für deinen Geschmack gut genug funktioniert (das Paket sollte sich auch für trusty bauen lassen).


    Das Nachlaufen wird nach meinen Beobachtungen auch noch durch zusätzliche Faktoren beeinflusst:

    • einen großen Einfluss hat die Frame-Wiederholung der Fernbedienungen (bei RC-5 und RC-6 senden Harmony-Fernbedienungen z.B. in der Voreinstellung 2 Wiederholungen - der Wert ist über verschiedene Fernbedienungen hinweg leider nicht wirklich konsistent, ich habe hier zwei Hauppauge A415, von denen eine 1 einen und die andere 2 wiederholte Frames sendet). Je nachdem ob man vor oder nach dem Beginn des nächsten Wiederholungszyklus loslässt, bekommt man bis zu 2 zusätzliche Tastendrücke. Wenn man die Frame-Wiederholung über die Konfigurationssoftware für die Harmony abschaltet, verschwindet der Effekt praktisch.
    • Die Ausgabe am TV ist je nach Bildmodus ein paar Frames verzögert, dadurch lässt man die Taste tendenziell zu spät los.
    • Das Zeichnen des OSD dauert mit aufwendigen Skins zu lange, auch hier sieht man das gewünschte Ergebnis zu spät und hält die Taste dadurch zu lange gedrückt

    Der irmp-Empfänger, den mir ranseyer damals zugeschickt hatte, ist leider sehr zickig beim Aushandeln der USB-Verbindung und funktioniert nur an einem alten Athlon64, aber nicht an meinem normalen Testsystem. Außerdem scheint er zumindest bei RC-5 die ersten paar Tastenwiederholungen zu verschlucken.

    Spräche etwas dagegen, dass wenn ein irmplircd-Paket installiert wird,automatisch eventlircd gestoppt wird und statt dessen irmplircd auf /var/run/lirc/lircd ausgibt (also da, wo vorher eventlircd ausgegeben hat)?

    Würdedas gehen, solange IRMP der einzige IR-Empfänger ist

    Kann irmplircd mittlerweile dynamisch einen später erkannten Empfänger einbinden? Der Charme bei der Lösung mit eventlircd ist in meinen Augen, dass es egal ist, wann die IR-Empfänger verfügbar sind. Mit Systemd muss man so nicht mal Abhängigkeiten definieren, sondern kann den Dienst bequem per Socket-Activation starten und VDR und KODI sind zufrieden, weil es sofort einen nutzbaren lirc-Sockel gibt. Außerdem hat man einen einheitlichen Namespace, was z.B. für die Lircmap.xml von KODI praktisch ist - dadurch heißen alle Fernbedienungen "devinput", sonst müsste man für jede lircd.conf und die ganzen anderen Daemons zusätzliche <altname> Tags setzen.


    Ansonsten kann man das System natürlich auch so konfigurieren, dass irmplircd statt eventlircd genutzt wird, nur sollte das IMHO eine explizit vom Nutzer gewünschte Konfiguration sein, keine Automatik.

    Gestern Plugin installiert, bumm VDR Tod

    Welches Plugin? Wenn sich der VDR mit dem Exit-Code 2 beendet, gibt es einen nicht-behebbaren Fehler. Das kann z.B. passieren wenn ein Plugin falsch konfiguriert wurde oder Berechtigungen nicht passen. Wie immer im Leben mit Linux hilft es die Logdateien aufmerksam zu lesen. Neben /var/log/syslog kann auch /var/log/upstart/vdr.log einen Blick wert sein.


    Die Einstellungen für den X-Server werden in der /etc/X11/xorg.conf.yavdr gesetzt, die Einstellungen der Plugins im Bezug auf die graphische Ausgabe über die setup.conf des VDR (oder Plugin-eigene Konfigurationsdateien).

    Punkt4: ist das mit den Images inzwischen eigentlich gefixed ? - EPGDATA hat da ja wohl was umgestellt und sendet nur noch links - kann die aktuelle Version aus dem GIT diese Images dann ziehen ?o

    Ich habe einen Patch dafür geschrieben, der den Download der Bilder wieder ermöglicht: epgd / epg2vdr / scraper2vdr - eine Einschränkung davon ist, dass es nicht funktioniert, wenn das epg2vdr-Plugin die Bilder aus der Datenbank lädt auf Dateisystemen Daten ablegt, für die (wie bei NTFS und FAT) viele Zeichen nicht erlaubt sind. Ich muss das also noch mal so anpassen, dass da möglichst unproblematische Dateinamen herauspurzeln, dann wird horchi das voraussichtlich übernehmen.

    Dach ich den Syntax noch nicht so ganz kapiert habe, habe ich mal daten aus einem Muster aus dem Git kopiert:

    Effektiv ordnest du die Kanal-Nummer aus der include.xml, die du von epgdata.com herunterladen kannst, der Channel-ID für den Kanal im VDR zu.

    Ich hoffe mal, dass die <-----> in Wirklichkeit Whitespace sind, den dein Editor anders anzeigt.


    Der VDR braucht das epg2vdr Plugin, das die EPG-Daten aus dem DVB-Stream holt. epgd führt die dann zusammen und diese Daten sollten dann im Webinterface auftauchen.


    Wenn du nachträglich weitere Senderzuordnungen in der channelmap.conf vorgenommen hast, kann es ein bisschen dauern, bis die berücksichtigt werden.

    Dass man sich extra heute einen Account erstellt, um dann kein Frage zum VDR zu stellen, sondern einen Link zur Hersteller-Webseite mit optimierter Wortwolke einstellt, hat schon ein gewisses Gschmäckle...


    Und dass es in anderen Foren und Kommentar-Feldern Benutzer mit dem gleichen Namen und genau einem Beitrag gibt ist schon interessant:

    Ich habe nach den ersten paar Google-Treffern aufgehört, weiteres Material scheint es genug zu geben...