[FYI] yavdr-ansible auf dem Raspberry Pi (Version 2 und 3)

Ich möchte den Onboard IR Empfänger nutzen

ir-keytable
/sys/class/rc/rc0/ gefunden mit:
        Name: sunxi-ir
        Treiber sunxi-ir
        Standardschlüsselcodeabbildung: rc-empty
        Eingabegerät: /dev/input/event0
        Linux-Infrarotfernbedienung : /dev/lirc0
        tangefügte BPF-Protokolle: Keine Berechtigung
        unterstützte Kernelprotokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm
        Aktivierte Kernelprotokolle: lirc
        zusätzliche Fähigkeiten: <Zugriff verweigert>

Ah cool, hab ich noch nicht gewusst. Hab ihn gerade über lirc jetzt mal am laufen aber wenn das so geht werd ich das mal versuchen.

Vielen Dank für die super Arbeit über all die Jahre!

Ich bin seit langen VDR- und yaVDR Nutzer und habe nun mal den Ansible Ansatz auf einem Raspberry Pi 3b+ ausprobiert:

*Minimale Anpassungen vorgenommen in host_vars/localhost

*Dort auch meine channels.conf angegeben

Ergebnis:

+TechnoTrend Connect S2-3600 USB funktioniert incl. Fernbedienung ohne weiteres

+TeVii S660 DVB-S2 USB funktioniert nach Firmware Installation.

(sudo cp dvb-fe-ds3000.fw /lib/firmware/ sudo cp dvb-usb-s660.fw /lib/firmware/)

FB funktioniert, aber manche Tasten brauchen wohl noch Überarbeitung

+Fernbedienung X10 "Medion" funktioniert ohne weiteres

+Empfang und Darstellung von HD und SD (mit gekauftem MPG2 Decode) funktioniert

aber:

-leider bleibt nach Kanalwechsel der Bildschirm schwarz, Ton funktionert meist.

Restart vdr bringt Bild zurück. Habe verschiedene Einstellung in rpihddevice probiert, aber keine Verbesserung.

Zum Vergleich habe ich noch MiniDVBLinux installiert:

Version: 5.4 (stable)

rpihddevice 1.0.4

vdr-plugin-rpihddevice 1:2018.07.16-42+2.4.1.218.26

Mit dieser Installation funktionieren die Kanalwechsel, aber die HD Sender werden sehr stark verzerrt dargestellt.

Was kann man tun, um das Kanalwechselproblem zu lösen?

Eventuell findet sich hier die Lösung?

Super - funktioniert!!

Sowohl Wechsel von SD auf HD und HD auf SD.

(getestet mit TechnoTrend Connect S2-3600. Dieses Device erzeugt bekanntermaßen kernel meldungen: "pctv452e: I2C error -121". Es gibt ein Firmwareupdate von 2018, das muss ich noch einspielen. Mal sehen, ob das hilft, oder ob die Meldungen langfristig stören, beim yavdr 06 war das nicht relevant)

Mal sehen, ob sich dieses Setup nun im Alltag bewährt - ich muss noch eine größere SSD anschliessen.

Nochmals vielen Dank!

Der Raspberry 3b+ läuft bei mir nun produktiv mit externer SSD als Datenspeicher. Interne Stromversorgung reicht.

DVB-S2 funktioniert sehr gut, auch bei Timeshift gibt es keine Ruckler etc.

Einzig die Wiedergabe von SDTV (Privatsender) ist nicht wirklich erträglich. Der Deinterlacer schafft es bei (schnellen) Bewegungen nicht, ein schönes Bild zu produzieren... Einstellmöglichkeiten habe ich dazu nicht gefunden.

Ist das ein prinzipielles Problem oder kann man da noch was machen?

(ich will noch einen Kühlkörper für den Prozessor nachrüsten - das kann sicher nicht schaden)

Danke, dann werde ich für SD gleich das TV nehmen - hat einen eingebauten Empfänger. Bei HD finde ich jedoch das Bild über den externen VDR besser und die Bedienung sowieso....

Ein VDR ist ja mehr als ein bloßer linearer Empfänger - "nichtlineares Ansehen" mit Überspringen von Werbung, Suche nach Genre, Thema, Stichwörtern ... und natürlich ein ausgefuchstes Interface in Verhältnis zu einem TV mit "Aufnahmemöglichkeit" auf einer USB-Festplatte ...

klar, ein VDR ist super... meiner sollte klein und vor allem lautlos sein... da wäre der Raspi ideal ... leider habe ich meinen lautlos umgebauten Acer Revo 3610 nun schon verkauft...

Vielen dank für die Option, yaVDR auch einfach auf einem Pi zu installieren!

Ich würde es auch begrüßen, wenn ihr im Launchpad repo parallel auch aarch64 anbieten könntet. Das KMS-basierte output-Plugin scheint ja Fortschritte zu machen, so dass das durchaus nutzbar werden könnte. Mit einem Rpi4 könnte dann 4k funktionieren.

Davon abgesehen hätte ich noch einen Vorschlag zum Betrieb auf einem Pi um SD-Wearing zu vermeiden (gerade durch logs): Read-Only Filesystem support.

Auf einem anderen Pi mit Raspotify benutze ich das schon basierend auf zu https://hallard.me/raspberry-pi-read-only/ und habe basierend darauf auch meinen Ansible-Yavdr auf RO-Betrieb umgestellt.

Zitat von seahawk1986

Es gibt im PPA schon grundsätzlich Pakete für arm64, nur noch kein paketiertes Ausgabeplugin, das man damit nutzen kann.

Ah, das ist merkwürdig. Ich hatte die Installation zunächst auf einer aarch64 Installation durchgeführt, aber das Ansible Script ist nicht durchgelaufen. Ich hatte dann im Eingangspost hier armhf gesehen und neu installiert und deswegen den genauen Fehler nicht mehr dokumentiert. Aber ich meine, es wurden entweder die PPAs nicht hinzugefügt und/oder zu installierende Pakete/Abhängigkeiten konnten nicht gefunden werden. Eine (ya)vdr-Installation kam jedenfalls nicht zustande.

Wenn Interesse besteht, kann ich hier nochmal mit einem anderen System oder einer frischen SD-Karte den Fall reproduzieren und berichten wo es hängt.

Zitat von seahawk1986

Das bringt halt eine Menge zusätzliche Komplexität mit rein - der VDR schreibt ja normalerweise einiges an Dateien (wenn das komplette Dateisystem read-only ist, sind nicht mal Änderungen in den Einstellungen des VDR und seiner Plugins persistent, man kann keine Timer anlegen, die einen Neustart überleben usw. und es gibt Anwender, die da epgd mit epg2vdr und scraper2vdr laufen lassen oder Aufzeichnungen machen wollen - wenn du im Wesentlichen Bedenken wegen der Logs hast, kannst du auch rsyslog runterwerfen und journald auf den RAM beschränken: https://www.freedesktop.org/so…urnald.conf.html#Storage= - ich finde die Möglichkeit Fehler nachvollziehen zu können im Zweifelsfall wichtiger als eingesparte Schreibzyklen, aber das darf jeder für sein eigenes System entscheiden.

Ja das ist mir alles bewusst. Ich nutze den Pi als reinen Client. Aufnahmen laufen auf einem headless vdr Server (auf dem NAS) von wo ich bei Start auch die epg.data kopiere und Aufnahmen per NFS exportiere. Ich kann nicht einschätzen, ob das eine typische oder untypische Nutzung ist, Standard sollte es jedenfaös nicht sein!

Neben weniger Beanspruchung der SD-Karte kommt auch noch der Vorteil, bei einem unsauberen Shutdown (z.B. bei Abbruch der Stromversorgung, Überhitzung, Spannungsunterversorgung des Pi) kein kaputtes Dateisystem zu haben. Auf SSDs und HDDs an PCs hatte ich damit nie Probleme, habe mir aber schon bei einigen RPis mit SD-Karte ein nicht oder schwer reparierbares Dateisystem zugezogen wenn plötzlich (meist durch Wackelkontakt an der Stromzufuhr) der Strom weg war.

Hallo,

habe erfolgreich ein solches System auf meinem Raspberry Pi 3b+ aufgesetzt. Danke für die Vorarbeit!

Aktuell hängt noch eine einfache USB Tastatur dran. Was muss ich tun, damit vdr sich damit bedienen lässt?

Damit ich dann einfach mit Flirc fernbedienen kann.

IR per GPIO (Pin 26) bekomme ich nicht hin. TT RC5 Fernbedienung ist vorhanden, ir-keytable -t zeigt auch codes an...

In /etc/rc_maps.cfgist gpio_ir_recv rc-tt-1500 /lib/udev/rc_keymaps/rc-tt-1500 gesetzt.

reboot, trotzdem wird rc-rc6-mce geladen.

root@ubuntu:/home/ubuntu# ir-keytable
/sys/class/rc/rc1/ gefunden mit:
        Name: Hauppauge WinTV-dualHD DVB
        Treiber em28xx
        Standardschlüsselcodeabbildung: rc-hauppauge
        Eingabegerät: /dev/input/event1
        Linux-Infrarotfernbedienung : /dev/lirc1
        unterstützte Kernelprotokolle: rc-5 nec rc-6
        Aktivierte Kernelprotokolle: rc-5
        bus: 3, Anbieter/Produkt: 2040:8265, Version: 0x0100
        Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms
/sys/class/rc/rc0/ gefunden mit:
        Name: gpio_ir_recv
        Treiber gpio_ir_recv
        Standardschlüsselcodeabbildung: rc-rc6-mce
        Eingabegerät: /dev/input/event0
        Linux-Infrarotfernbedienung : /dev/lirc0
        tangefügte BPF-Protokolle: Vorgang wird nicht unterstützt
        unterstützte Kernelprotokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon rc-mm
        Aktivierte Kernelprotokolle: lirc rc-6
        bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
        Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms
root@ubuntu:/home/ubuntu# ir-keytable -c
alte Schlüsseltabelle geleert
root@ubuntu:/home/ubuntu# ir-keytable -p RC-5
Protokolle geändert in rc-5
root@ubuntu:/home/ubuntu# ir-keytable -a /lib/udev/rc_keymaps/rc-tt-1500
ungültiger Parameter in Zeile 2 von /lib/udev/rc_keymaps/rc-tt-1500
ir-keytable: Lesen der Konfigurationsdatei /lib/udev/rc_keymaps/rc-tt-1500 fehlgeschlagen
Try `ir-keytable --help' or `ir-keytable --usage' for more information.

manuelles keytable laden: ir-keytable -a /lib/udev/rc_keymaps/rc-tt-1500 funktioniert nicht.

eventlircd habe ich gestoppt:

systemctl stop eventlircd.socket eventlircd.service

Ich blicke das nicht. Bin für Hilfe dankbar.

Bin mir nicht 100% sicher zu welchem Zeitpunkt ich die Tatstatur angesteckt habe... jetzt nochmal neu installiert und es ist wie Du schreibst: 99-rpi.conf ist da. (Installation über ssh)

Jetzt fällt mir auf das Tab (für Menu) nicht geht. In der remote.conf steht es richtig:

...
XKeySym.Up         Up
XKeySym.Down       Down
XKeySym.Menu       Home
XKeySym.Menu       Tab
XKeySym.Menu       KP_Home
XKeySym.Ok         Return
...

Zitat von seahawk1986

Welche Tastendrücke sendet der Flirc-Empfänger?

Yavdr übliche Tastaturbelegung. Z.B. auch Tab für Menu. Stecke ich den Flirc Empfänger in den Nuc vdr, funktioniert Tab für Menu (remote.conf Einträge: XKeySam.* sind auf beiden Systemen gleich)

Am Raspberry geht Tab weder über Flirc noch über Tatstatur. Viele andere Tasten wie 1,2,3 usw. oder auch Pfeiltasten funktionieren für die Bedienung.

Komisch.

IR über GPIO ist die Alternative. Die Datei /lib/udev/rc_keymaps/rc-tt-1500 sieht so aus:

# table rc-tt-1500 type: rc-5
0x1501 KEY_POWER2
0x1522 KEY_EPG
0x1512 KEY_INFO
0x150d KEY_UP
0x1511 KEY_DOWN
0x150e KEY_LEFT
0x1510 KEY_RIGHT
0x150f KEY_OK
0x1513 KEY_ESC
0x1502 KEY_MENU
0x1525 KEY_VOLUMEUP
0x1526 KEY_VOLUMEDOWN
0x1523 KEY_CHANNELUP
0x1524 KEY_CHANNELDOWN
0x1518 KEY_MUTE
0x153a KEY_RECORD
0x153b KEY_PLAY
0x153e KEY_PAUSE
0x153c KEY_STOP
0x153d KEY_REWIND
0x153f KEY_FASTFORWARD
0x1503 KEY_1
0x1504 KEY_2
0x1505 KEY_3
0x1506 KEY_4
0x1507 KEY_5
0x1508 KEY_6
0x1509 KEY_7
0x150a KEY_8
0x150b KEY_9
0x150c KEY_0
0x1519 KEY_TEXT
0x151a KEY_SUBTITLE
0x1514 KEY_RED
0x1515 KEY_GREEN
0x1516 KEY_YELLOW
0x1517 KEY_BLUE

Setze ich vor Zeile 2 ein #, meckert er Zeile 3 als ungültigen Parameter an.