Beiträge von Dr. Seltsam

    Anscheinend liegt es daran, dass neben lircd auch lircd-uinput läuft. Wenn ich den kille, sind die Probleme weg. Ich dachte, ich hätte das Starten von lircd-uinput bereits durch die Einträge im Abschnitt [lircmd] unterbunden, aber anscheinend ist das dafür nicht zuständig. Ich hoffe, dass ein

    Code
    1. sudo systemctl disable lircd-uinput.service

    das jetzt dauerhaft behebt.


    Da hat sich offenbar allerlei bei lirc geändert. Was mir auch noch auffiel ist, dass irrecord trotz Aufruf über sudo nur noch dann funktioniert, wenn zusätzlich der Parameter

    Code
    1. -k --keep-root Don't drop root privileges

    gesetzt wird. Sonst startet irrecord zwar, reagiert aber auf keinen Tastendruck. Ein weiteres Problem mit irrecord ist, dass es bei mir ständig mit einem segfault abstürzt, wenn die Konfiguration abgespeichert werden soll. Man findet dann noch temoräre Dateien (irrecord-tmp-[xyz]) in denen hinter jedem Code ein zweiter Eintrag "0xFFFFFFFFFFFFFFFF" steht. Wenn man den manuell löscht, kann man mit der temporären Datei weiterarbeiten, sie muss dann mit der Option

    Code
    1. -u --update Amend buttons to existing file

    aufgerufen werden. Das ging früher glaube ich auch ohne, wenn man eine vorhandene conf vorgab um zusätzliche Tasten anzulernen. Ohne den -u Parameter fängt irrecord jetzt wieder ganz von vorne an.

    ich führe weiter Selbstgespräche...


    Leider musste ich feststellen, dass die Fernbedienung ohne lirc und nur über den Kernel erheblich träger läuft. Ich habe bereits mit delay und repeat-Werten gespielt, aber flüssiges Scrollen durch die Menüs ist damit nicht möglich. Die gleiche FB über lircd läuft super flott.

    So sieht meine lirc_options.conf in Ubuntu 18.04 aus:




    inputlirc ist deinstalliert, und ganz wichtig ist die Deaktivierung von lircd-uinput im Abschnitt [lircmd]. Den Abschnitt

    [modinit] habe ich noch auskommentiert, da ich serial-ir über einen Eintrag in /etc/modules in Verbindung mit einer Konfigurationsdatei in /etc/modprobe.d starte.


    Nun gibt es aber ein unerwartetes Problem, da sich in meiner 15jährigen vdr-Laufbahn bisher nicht hatte:

    Direkt nach dem Start funktionieren einige Tasten nicht richtig. Ich weiss nicht mal, ob es die Tasten sind oder vdr. Immerhin spielt es dabei keine Rolle, ob ich die FB oder die Tastatur zur Steuerung benutze. Folgendes Phänomen: Beim Umschalten wird die Kanalanzeige nicht eingeblendet. Drücke ich kurz auf die ok-Taste, blitzt die Kanalanzeige für einen Sekundenbruchteil auf. Die Zifferntasten funktionieren auch nicht. Man sieht auch hier ganz kurz eine OSD-Einblendung, aber der vdr reagiert nicht auf die Taste bzw. schaltet das Programm nicht um. Andere Tasten bzw. Funktionen funktionieren einwandfrei. Welches OSD ich verwende, spielt keine Rolle. Wenn ich vdr ohne die --lirc-Option starte und nur über die Tastatur steuere, ist es das gleiche. Aber: nach ein paar Minuten gibt sich das von selbst. Mir fällt auf, dass die load am Anfang auch sehr hoch ist (über 1) und danach auf 0,03 fällt.
    im Log ist nichts zu sehen. vdr loggt überhaupt nichts beim Drücken der nicht reagierenden Tasten.


    mühsam nährt sich das Eichhörnchen...


    Ich habe es jetzt mit inputlirc versucht. Das lief auch schon mal. Nun kriege ich aber nur noch

    Code
    1. Apr 27 14:57:55 ubuntuvdr1 inputlircd[1600]: /dev/input/event12 100013
    2. Apr 27 14:57:55 ubuntuvdr1 inputlircd[1600]: Unable to bind AF_UNIX socket to /var/run/lirc/lircd: No such file or directory
    3. Apr 27 14:57:55 ubuntuvdr1 systemd[1]: inputlirc.service: Main process exited, code=exited, status=71/n/a
    4. Apr 27 14:57:55 ubuntuvdr1 systemd[1]: inputlirc.service: Failed with result 'exit-code'.


    /etc/default/inputlirc:

    Code
    1. # Options to be passed to inputlirc.
    2. #EVENTS="/dev/input/event12"
    3. EVENTS="/dev/input/by-path/platform-serial_ir.0-event-ir"
    4. OPTIONS="-d /var/run/lirc/lircd -g -m 0"


    Das device ist richtig.

    Nach meinem Verständnis sollte der Socket /var/run/lirc/lircd doch gerade von inputlirc angelegt werden - wieso kommt da eine Fehlermeldung, dass es den nicht gibt? Wer sonst sollte das Socket anlegen?


    Mit dem remote-Plugin geht es. Gibt es aber wirklich keine einfachere Alternative? Ich glaube, die Unterstützung von anderen Kernel-Inputdevices als Keyboards sollte auf die To-Do-Liste für vdr 2.5

    ich habe jetzt lirc komplett deinstalliert, weil es nach jedem Neustart nicht mehr funktionierte und ich einfach nicht heraus bekam, wo es hakte. Es gibt also weder eine /etc/lirc noch lircd . Stattdessen will ich es nun mal auf die neue, angeblich einfachere Art versuchen.


    Erstes Problem war, dass der Eintrag "setserial /dev/ttyS0 uart none" in /var/lib/setserial/autoserial.conf anscheinend beim Laden von serial-ir unberücksichtigt bleibt, nachdem dieses Modul nun über einen Eintrag in /etc/modules geladen wird. Erst nachdem ich eine /etc/modprobe.d/serial-ir.conf mit dem Inhalt

    Code
    1. install serial_ir setserial /dev/ttyS0 uart none; modprobe --ignore-install serial_ir

    angelegt hatte, funktionierte es.


    Ich habe bereits eine keymap angelegt. Das ging mit der Anleitung von MarMic auch ganz gut. Ich musste mich dazu allerdings von dem bisher genutzen Code eines Aiwa-VCRs trennen, da dessen Codes von keinem Protokoll erkannt wurden.


    Das Laden der keymap mit Vorgabe des richtigen Protokolls übernimmt im Moment noch der Eintrag

    Code
    1. ir-keytable -s rc0 -c -p rc-6 -w /etc/rc_keymaps/Ru880_Kabel_004

    in /etc/rc.local


    Die Syntax von /etc/rc_maps.cfg (driver - table - file) verstehe ich nämlich noch nicht so ganz. Im Kopf der standardmäßig bereits vorhandenen Datei steht

    Zitat

    table - RC keymap table, provided via uevent - use * for any table

    Was ist die "RC keymap table"? Und wie gebe ich das Protokoll vor?


    Ist /etc/rc_maps.cfg das Ubuntu-Equivalent zu /etc/rc_maps.conf?


    ir-keytable sagt nun:

    Code
    1. /sys/class/rc/rc0/ gefunden (/dev/input/event14) mit:
    2. Name: Serial IR type home-brew
    3. Treiber: serial_ir, Tabelle: rc-rc6-mce
    4. Lirc Gerät: /dev/lirc0
    5. unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    6. Aktivierte Protokolle: lirc rc-6
    7. bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
    8. Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

    Im syslog steht

    Code
    1. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.918418] serial_ir serial_ir.0: auto-detected active low receiver
    2. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.927287] lirc_dev: IR Remote Control driver registered, major 240
    3. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.994552] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
    4. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.994690] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input14
    5. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.995267] lirc lirc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0

    Wie schaffe ich es nun, dass vdr auf diese Fernbedienung hört? Wenn ich vdr mit der lirc-Option starte, hagelt es Fehlermeldungen

    Code
    1. ERROR (lirc.c,43): /var/run/lirc/lircd: Datei oder Verzeichnis nicht gefunden

    Brauche ich jetzt das remote-Plugin? Oder eventlirc? Oder das inputdev-Plugin?



    Ich blicke hier trotzdem nicht durch...

    Meine Fernbedienung ist eine programmierbare Fernbedienung, wo ich unter der für den VDR vorgesehenen Gerätetaste die Codes eines Aiwa-Videorekorders programmiert habe. Dazu habe ich bereits eine passende lircd.conf.


    Nachdem ich nun in der /etc/lirc/lircmd.conf den Eintrag

    driver = devinput

    auf

    driver = default

    geändert habe, läuft die Fernbedienung über /dev/lirc0 und lircd statt /dev/input/event15. Das funktioniert also.


    Was müsste ich denn tun, um auf lircd verzichten zu können? Wie kann ich dem Treiber beibringen, dass er mit Protokoll rc-5 statt rc-6 arbeiten soll? Gibt es eine Möglichkeit, die lircd.conf in eine keymap umzuwandeln?



    Moin,

    mit Ubuntu 18.04 beisse ich mir im Moment noch die Zähne aus.


    Das sieht soweit ganz gut aus:


    Code
    1. [ 715.696863] serial_ir serial_ir.0: auto-detected active low receiver
    2. [ 715.706154] lirc_dev: IR Remote Control driver registered, major 240
    3. [ 715.710794] IR LIRC bridge handler initialized
    4. [ 715.744854] Registered IR keymap rc-rc6-mce
    5. [ 715.750690] IR RC6 protocol handler initialized
    6. [ 715.776991] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
    7. [ 715.777130] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input16
    8. [ 715.777559] lirc lirc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0


    Ich sehe bei jedem Tastendruck die grüne LED vom atric-Einschalter blinken. Es passiert aber nichts. Auch irrecord erkennt keinen Tastendruck. Was mich stutzig macht ist der Hinweis "IR RC6 protocol handler initialized". Ich meine, dass meine FB nur RC5 kann. Laut ir-keytable kann der Lirc-Receiver zwar RC5, aber es sit anscheinend nur das Protokoll RC6 aktiviert.

    Code
    1. martin@ubuntuvdr1:/tmp$ sudo ir-keytable
    2. /sys/class/rc/rc0/ gefunden (/dev/input/event15) mit:
    3. Name: Serial IR type home-brew
    4. Treiber: serial_ir, Tabelle: rc-rc6-mce
    5. Lirc Gerät: /dev/lirc0
    6. unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    7. Aktivierte Protokolle: lirc rc-6
    8. bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
    9. Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

    Kann das eine Erklärung sein, warum der IR-Receiver nichts empfängt? Wie kann ich das Protokoll wechseln?

    wow, vielen Dank!

    Nach Ändern der /etc/systemd/logind.conf konnte ich meine vorhandenen Dateien wieder verwenden. Deine Scripte, Saman,muss ich mir ebenso wie das Projekt von M-Reimer in einer ruhigen Minute mal genauer anschauen, das ist viel umfangreicher als meine bisherige Umsetzung.

    Die Powertaste der Fernbedienung veranlasst bei mir den atrci-Einschalter, die power-Kontakte auf dem Mainboard zu schließen. Ich war es gewohnt, das Runterfahren des VDRs (egal ob per FB oder Gehäuseschalter) und den vorherigen Aufruf eines acpi-wakeup-Scripts über /etc/acpi/powerbtn.sh zu steuern.


    Bei Ubuntu 18.04 finde ich in /etc/acpi aber nichts mehr, was auf den Powerschalter hindeutet. Dennoch funktioniert dieser. Wie ist das realisiert, und wie muss ein acpi-wakeup-Script nun eingebunden werden? Hat das was mit systemd zu tun?

    Hallo Klaus,

    wahrscheinlich hätte ich den neuen VDR gleich mit Version 2.3.9 aufsetzen sollen, aber nun bin ich schon fast fertig... deshalb würde ich gerne den Fix in meine 2.2.0 backportieren. Das Diff von 2.3.8 zu 2.3.9 ist ja riesig - kannst Du vielleicht übersehen, welche Stelle(n) hier entscheidend war(en)?

    Es ist merkwürdig, dass das Poblem auf meinem alten VDR nie auftrat. Liegt das evtl. an Änderungen in glibc oder gcc?

    Beim Probieren mit Ubunbtu 18.04 starte ich vdr 2.2.0 auf der Konsole über eine ssh-Verbindung:

    Code
    1. vdr --user=martin -P'softhddevice -d:0 -f -v vdpau' -Ppulsecontrol

    Beim Beenden per Strg-C kommt fast jedes mal


    Code
    1. terminate called without an active exception
    2. Abgebrochen (Speicherabzug geschrieben)


    Das backtrace sagt:


    ... und sieht auch jedesmal gleich aus.


    Was bedeutet das nun?

    Es wird immer eine natürliche Fluktuation geben. Nur scheinen kaum noch neue User hinzuzukommen. Das hat m.E. auch etwas damit zu tun, dass die Hürden für einen Neueinsteiger selten so hoch waren. Wenn die Leute es geschafft haben, vdr zu kompilieren und dann das Programm starten, stellen sie erstmal fest, dass kein Bild kommt. Wer schlau ist, realisiert irgendwann, dass er ein Ausgabeplugin braucht. Wenn man dann feststellt, dass es diverse forks und branches gibt und auch die Version von ffmpeg noch eine Rolle spielt, vergeht einem Einsteiger schnell die Lust. Mal sehen was für Kommentare wir diesmal bekommen, wenn das Erscheinen von vdr 2.4 in diversen Portalen und Magazinen gewürdigt wird und die ersten Neueinsteiger hier im Forum landen.

    o.k., dann schau mal, ob Du die Dose wieder in die wand kriegst, und wie lang das Kabel dann ist, wenn man den verbogenen Stecker (es müsste auf der Dosenseite ja eine Buchse bzw. Kupplung sein) abschneiden würde.


    Kannst Du auf der TV-Seite den Stecker (den ich nach dem Foto für eine Kupplung halte) so direkt in die Antennebuchse des TV stecken? Oder ist da noch ein Adapter im Spiel, der aus der Buchse einen Stecker macht?

    Wenn das Kabel nämlich falsch herum verlegt ist und Du an der Dose einen Stecker hast, kannst Du den ja nur in die Radiobuchse der Antennendose stecken. Bei manchen Dosen liegt an beiden Ausgängen (Radio und TV) das gleiche volle Frequenzspekztrum an, bei manchen ist der Radioausgang kastriert. Auch das könnte Deine Probleme erklären.

    Komisch, für mich sieht das auf dem 2. Bild wie eine Koax-Buchse bzw. Kupplung (female) aus und nicht wie ein Stecker (male) ...

    Um wieviele Meter von der Dose bis zum TV geht es denn? Kannst Du den TV sonst zur Dose hin tragen, um ihn mit einem normalen kurzen Kabel testweise direkt an der Dose anzuschließen?

    Kann auch sein dass das Kabel die Störungsursache war. Ich vertraue fertig konfektionierten Kabeln mit normaler Plastikummantelung und vergossenem Stecker mehr.

    sehr mysteriös. Den Sourcen nach wurde da nichts verändert. Entweder die Pakete werden derzeit noch gar nicht unter Bionic selbst kompiliert, oder Ubuntu hat in letzter Minute eine neue Compilerversion verteilt.


    In remux.c habe ich das gleiche Problem:

    Code
    1. remux.c:1559:52: error: call of overloaded ‘abs(uint32_t)’ is ambiguous
    2. else if (abs(Delta - 1800) <= 1)


    Delta ist ein uint32_t. Also habe ich da jetzt auch mal das abs rausgenommen. Ebenso bei einer gleichartigen Stelle 4 Zeilen tiefer. Jetzt kompiliert vdr durch.

    Die Dose muss nicht unbedingt was abgekriegt haben. Die beiden Haltezungen verhindern normalerweise, dass die Dose aus der Unterputz-Hohldose rausfällt. Ich würde jetzt erstmal prüfen, ob sich der Stecker noch von der Dose lösen lässt, und ob die Dose sich wieder in der UP-Hohldose fixieren lässt (die Haltezungen sind geschraubt).

    Bei der Gelegenheit kannst Du mal schauen, um was für eine Dose es sich überhaupt handelt (Hersteller, Bezeichnung).


    Das eingeputzte Kabel mit dem vermutlich defekten Stecker ist ein anderes Problem. Wenn der Stecker hin ist, wird nach dem Abschneiden evtl. nicht mehr genug Platz sein, um einen neu montierten Stecker wieder in die Dose stecken zu können. Im Zweifelsfall legst Du lose ein neues fertig konfektioniertes Kabel bis zum TV. Wer weiss, ob das alte Kabel überhaupt etwas taugt. Poste doch mal ein Foto vom anderen Ende des Kabels - geht das in eine Dose, oder endet es in einem Stecker?


    Ich würde jetzt auch mal schauen, ob direkt an der Dose der Empfang besser ist.