epgsync und remoteosd benötigen Anpassungen an den VDR 2.4.0, ich habe die gerade aus dem Ubuntu-Paket und dem MLD-Git zusammengesucht und eingebaut - probier mal bitte, ob das bei dir funktioniert, wenn die beiden Pakete im PPA gebaut und veröffentlicht wurden.
yavdr ansible
-
-
Also damit hätte ich nicht gerechnet
Und das an einem solchen Tag !
Sobald es ein bißchen ruhiger wird (in ein paar Tagen), werde ich das sofort testen und Bescheid geben.
Genieß die Feiertage und besten Dank.
-
Beide Plugins funktionieren aus meiner Sicht einwandfrei - Weltklasse.
Einer Produktivsetzung meiner erneuerten VDR-Landschaft auf Basis yavdr ansible steht nun nichts mehr im Weg (ausser fehlender Zeit).
Vielen Dank für diese tolle Arbeit.
-
Ich habe nun auch einmal die ansible Installtion getestet.
Beim installieren von vdr-plugin-skindesigner bekomme ich folgende Fehlermeldung:
Codevdr-plugin-skindesigner (1.2.7-5yavdr0~bionic) wird eingerichtet ... libdvd-pkg: Checking orig.tar integrity... /usr/src/libdvd-pkg/libdvdcss_1.4.2.orig.tar.bz2: OK libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
Das Paket stammt vom YAVDR PPA:
Code# apt-cache policy vdr-plugin-skindesigner vdr-plugin-skindesigner: Installiert: 1.2.7-5yavdr0~bionic Installationskandidat: 1.2.7-5yavdr0~bionic Versionstabelle: *** 1.2.7-5yavdr0~bionic 500 500 http://ppa.launchpad.net/yavdr/experimental-vdr/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status
Das fehlende oder falsche Paket kommt vom Ubuntu PPA:
Code# apt-cache policy libdvd-pkg libdvd-pkg: Installiert: 1.4.2-1-1 Installationskandidat: 1.4.2-1-1 Versionstabelle: *** 1.4.2-1-1 500 500 http://de.archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu bionic/multiverse i386 Packages 100 /var/lib/dpkg/status
Nutzen tue ich zur Zeit nur die von Ansible bereitgestellten und eines von mir welches gegen die YaVDR PPAs baut:
-
Probier mal sudo dpkg-reconfigure libdvd-pkg laufen zu lassen, in https://bugs.launchpad.net/ubu…e/libdvd-pkg/+bug/1802321 wurde das schon als Bug für Ubuntu 18.10 und Ubuntu 18.04 gemeldet.
-
Das hat geholfen:
Code
Alles anzeigen# dpkg-reconfigure libdvd-pkg libdvd-pkg: Checking orig.tar integrity... /usr/src/libdvd-pkg/libdvdcss_1.4.2.orig.tar.bz2: OK libdvd-pkg: Unpacking and configuring... libdvd-pkg: Building the package... (it may take a while) libdvd-pkg: Build log will be saved to /usr/src/libdvd-pkg/libdvdcss2_1.4.2-1~local_amd64.build Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_wake_alarm,cap_block_suspend,cap_audit_read Securebits: 024/0x14/5'b10100 secure-noroot: no (unlocked) secure-no-suid-fixup: yes (unlocked) secure-keep-caps: yes (unlocked) uid=0(root) gid=0(root) groups=0(root) libdvd-pkg: Installing... Vormals nicht ausgewähltes Paket libdvdcss2:amd64 wird gewählt. (Lese Datenbank ... 143800 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../libdvdcss2_1.4.2-1~local_amd64.deb ... Entpacken von libdvdcss2:amd64 (1.4.2-1~local) ... Vormals nicht ausgewähltes Paket libdvdcss-dev:amd64 wird gewählt. Vorbereitung zum Entpacken von .../libdvdcss-dev_1.4.2-1~local_amd64.deb ... Entpacken von libdvdcss-dev:amd64 (1.4.2-1~local) ... libdvdcss2:amd64 (1.4.2-1~local) wird eingerichtet ... libdvdcss-dev:amd64 (1.4.2-1~local) wird eingerichtet ... Trigger für libc-bin (2.27-3ubuntu1) werden verarbeitet ...
-
ich komm mit dem "neuen" Lirc jetzt nicht ganz zurecht, wie wird es konfiguriert um einen artic ir Einschalter, oder generell serial anzusprechen? es wird ja nichtmehr über die hardware.conf gesteuert oder?!
-
ich komm mit dem "neuen" Lirc jetzt nicht ganz zurecht, wie wird es konfiguriert um einen artic ir Einschalter, oder generell serial anzusprechen?
Lese mal in diesem Thread ab Beitrag #215, da wird einiges zum "serial_ir" geschrieben, welches das alte "lirc_serial" ersetzt und wie es konfiguriert werden muss.
Auf jeden Fall musst Du eine "ir_keytable" benutzen, an Stelle der alten "lircd.conf".
Einige "ir_keytable" für die gängigsten Fernbedienungen sind schon in yavdr-ansible enthalte. Wenn nicht, dann musst Du eine eigene erstellen, aber das ist sehr einfach und wie das geht ist in dem von mir verlinkten Tutorial beschrieben (Beitrag #221)
Paul
-
Ich bin immer noch nicht dazu gekommen das mit meinem Atric V5 auszuprobieren, aber das Wichtigste ist die Serielle Schnittstelle in den richtigen Modus zu bekommen und den serial_ir Treiber mit den passenden Optionen zu laden. Lirc braucht man dann soweit ich das gelesen habe nicht zwingend, weil serial_ir als rc-core Treiber arbeitet und eventlircd diese Geräte direkt einbinden kann.
Ich würde es mal so probieren (ggf. musst du die Konfigurationsdateien anpassen wenn du einen anderen seriellen Port nutzt):
Code: /etc/modprobe.d/serial_ir.conf#COM1 equivalent, /dev/ttyS0 options serial_ir irq=4 io=0x3f8 #COM2 equivalent, /dev/ttyS1 #options serial_ir irq=3 io=0x2f8 install serial_ir setserial /dev/ttyS0 uart none; /sbin/modprobe --ignore-install serial_ir
Dann wollen wir, dass das Modul beim Start automatisch geladen wird:
Und setserial (das kann man aus dem gleichnamigen Paket installieren: sudo apt install setserial) sollte die gewünschte Konfiguration für die Serielle Schnittstelle kennen:
Code: /etc/serial.conf#COM1 equivalent, /dev/ttyS0 /dev/ttyS0 uart none #COM2 equivalent, /dev/ttyS1 #/dev/ttyS1 uart none
Wenn das passt, solltest du nach einem Reboot in der Ausgabe von sudo ir-keytable einen Empfänger sehen, der serial_ir als Treiber nutzt.
Falls nicht, brächte ich ein Log vom Start des Systems, eventuell muss man da mit der Reihenfolge noch etwas tricksen.
Wenn man dann die aktuell geladene Keytable löscht (sudo ir-keytable -c) und das gewünschte IR-Protokoll mit sudo ir-keytable -p PROTOCOL setzt (die unterstützen Protokolle sollten dir in der Ausgabe des ersten ir-keytable Befehls angezeigt worden sein), müsste man mit sudo ir-keytable -t Tastendrücke sehen können.
Dann kann man sich wie in https://www.yavdr.org/document…html#_scancodes_ermitteln ff. beschrieben eine Keytable erstellen oder eine der vorgefertigten nutzen: https://github.com/yavdr/yavdr-remote/tree/master/rc_keymaps und über einen Eintrag in der /etc/rc_maps.cfg beim Start laden lassen.
-
@Seahawk, Vielen Dank für die detailierte Anleitung zur Inbetriebnahme des Seriellen Fernbedienung Empfängers.
Bei manuellem Vorgehen (sudo ir-keytable -c, sudo ir-keytable -p rc-5, sudo ir-keytable -w /etc/rc_keymaps/rc-TTS35AI04) funktionert die Technisat TTS35AI Fernbedinung prima.
Aber nach dem nächsten Reboot ist wieder der Default geladen, und sudo ir-keytable) listet:
"Name: Serial IR type home-brew
Treiber: serial_ir, Tabelle: rc-rc6-mce
...
Aktivierte Protokolle: lirc rc-6
..."
Mein Versuch in der /etc/rc_maps.cfg
"* rc-TTS35AI04 /etc/rc_keymaps/rc-TTS35AI04" als ersten Eintrag zu addieren hat leider nicht funktioniert.
Welcher Eintrag in welcher Datei steuert das Laden der Remote Tabelle und wie ist die korrekte Syntax?
Bernhard
-
Das IR-Protokoll kann man in der Kopfzeile der Keymap angeben, also z.B.
Es gibt im Paket für ir-keytable die /lib/udev/rules.d/60-ir-keytable.rules, über die das Laden der Keytable(s) gemäß den Regeln in der /etc/rc_maps.cfg ausgelöst wird. und für die Regel in der /etc/rc_maps.cfg würde ich folgendes probieren (die Bezeichnung der erwarteten Keymap ist vorgegeben, deswegen ist es meistens einfacher die zu übernehmen):
-
@Seahawk, Danke sehr, die Modifikation der /etc/rc_maps.cfg funktioniert prima.
-
Prima, dann gibt es jetzt auch eine funktionierende Lösung für die seriellen Empfänger
Ich habe mal eine Ansible-Rolle für die Konfiguration von seriellen "homebrew" Empfängern angelegt (muss man im Playbook einkommentieren, da man die seriellen Empfänger leider nicht automatisiert erkennen lassen kann) und das Template für die rc_maps.cfg um einen Eintrag für serial_ir erweitert, der eine für yaVDR angepasste rc-rc6-mce Keymap lädt.
-
Vielen dank euch, ich kannte bisher nur das gute alte Lirc.
aber ich steh jetzt noch bisl auf dem schlauch, ich bekomme:
Code
Alles anzeigenEreignisse werden getestet. Bitte drücken Sie STRG-C, um abzubrechen. 7464.624414: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7464.624414: Ereignistyp EV_KEY(0x01) key_runter: KEY_OK(0x0160) 7464.624414: Ereignistyp EV_SYN(0x00). 7464.731116: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7464.731116: Ereignistyp EV_SYN(0x00). 7464.892080: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7464.892080: Ereignistyp EV_SYN(0x00). 7465.152025: Ereignistyp EV_KEY(0x01) key_hoch: KEY_OK(0x0160) 7465.152025: Ereignistyp EV_SYN(0x00). 7467.762911: Ereignistyp EV_MSC(0x04): Scancode = 0x800f041e 7467.762911: Ereignistyp EV_KEY(0x01) key_runter: KEY_UP(0x0067) 7467.762911: Ereignistyp EV_SYN(0x00). 7467.924105: Ereignistyp EV_MSC(0x04): Scancode = 0x800f041e 7467.924105: Ereignistyp EV_SYN(0x00). 7468.184074: Ereignistyp EV_KEY(0x01) key_hoch: KEY_UP(0x0067) 7468.184074: Ereignistyp EV_SYN(0x00). 7469.961829: Ereignistyp EV_MSC(0x04): Scancode = 0x800f041e 7469.961829: Ereignistyp EV_KEY(0x01) key_runter: KEY_UP(0x0067) 7469.961829: Ereignistyp EV_SYN(0x00). 7470.128089: Ereignistyp EV_MSC(0x04): Scancode = 0x800f041e 7470.128089: Ereignistyp EV_SYN(0x00). 7470.388021: Ereignistyp EV_KEY(0x01) key_hoch: KEY_UP(0x0067) 7470.388021: Ereignistyp EV_SYN(0x00). 7474.235099: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7474.235099: Ereignistyp EV_KEY(0x01) key_runter: KEY_OK(0x0160) 7474.235099: Ereignistyp EV_SYN(0x00). 7474.396027: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7474.396027: Ereignistyp EV_SYN(0x00). 7474.652072: Ereignistyp EV_KEY(0x01) key_hoch: KEY_OK(0x0160) 7474.652072: Ereignistyp EV_SYN(0x00). 7477.155335: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7477.155335: Ereignistyp EV_KEY(0x01) key_runter: KEY_OK(0x0160) 7477.155335: Ereignistyp EV_SYN(0x00). 7477.320029: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0422 7477.320029: Ereignistyp EV_SYN(0x00). 7477.576075: Ereignistyp EV_KEY(0x01) key_hoch: KEY_OK(0x0160)
und
Code/sys/class/rc/rc0/ gefunden (/dev/input/event15) mit: Name: Serial IR type home-brew Treiber: serial_ir, Tabelle: rc-rc6-mce Lirc Gerät: /dev/lirc0 unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp Aktivierte Protokolle: lirc rc-6 bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100 Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms
am VDR gehen direkt die Cursor und Lautstärke Tasten, also läuft da schon was, aber der rest nicht, Fernbedienung ist eine MCE bzw, über Harmony MCE Profil, müßte ich jetzt einfach eine Remote.conf erstellen mit den passenden Hex? Da MCE aber ja eigentlich die weit verbreitete ist, müßte da ja schon was fertiges da sein oder?
-
Da MCE aber ja eigentlich die weit verbreitete ist, müßte da ja schon was fertiges da sein oder?
Ja, da haben wir mindestens eine passende Keytable im Paket yavdr-remote Du brauchst in der /etc/rc_maps.cfg noch einen Eintrag, der die lädt, also z.B. (wie es mittlerweile auch im Template für die Datei im Git enthalten ist ) :
Alternativ kannst du statt der rc-rc6-mce auch die HOPLOrc6 Keymap ausprobieren.
-
Vielen Dank für die Einarbeitung des serial_ir Templates.
Ich habe dieses in einer neuen Testinstallation geprüft.
In der rc_maps.cfg steht die Zeile
"# rc-rc6-mce
* rc-rc6-mce /lib/udev/rc_keymaps/rc-rc6-mce"
oberhalb der Zeilen
"# serial ir (e.g. Atric V5)
serial_ir rc-rc6-mce /lib/udev/rc_keymaps/rc-rc6-mce"
Daher triggert die rc-rc6-mce (wahrscheinlich aufgrund des Sterns) die Auswahl der Key Table auch für den serial_ir Receiver
und die serial_ir Zeile wird ignoriert.
Um eine andere serial_ir Key Tabelle zu laden, muß die serial_ir Zeile in der rc_maps.cfg vor die rc-rc6-mce Zeile verschoben werden.
Eventuell sollte die Verschiebung auch in der rc_maps.cfg Template Datei im git vorgenommen werden.
-
Guter Fund, ich habe die Reihenfolge der Einträge mal angepasst.
-
Unter yavdr-ansible passen die Fonts aus dem Paket vdrsymbols-ttf anscheinend nicht mehr zum vdr-plugin-extrecmenu.
Im OSD werden anstelle der Einrückungen und des "Film Gestartet Kringels" "Kästchen" angezeigt.
Gibt es hierzu Abhilfe?
Wenn ja, welche Fonts werden benötigt?
Gehören die Fonts immer noch nach /usr/share/fonts/truetype/?
Bernhard
-
Man könnte z.B. das Paket fonts-vdropensans installieren und die Schrift in den Einstellungen fürs OSD auswählen.
-
Vielen Dank für die schnelle Antwort,
vdrsymbols-ttf funktioniert weiterhin mit dem vdr-plugin-extrecmenu.
Die Einstellung der Schrift im OSD hatte gefehlt.
Bernhard
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!