Beiträge von seahawk1986

Die CIR-Empfänger laufen nicht über lircd2uinput, sondern die Events gehen direkt von dem vom rc-core Treiber angelegten Kernel Input Device an eventlircd.

Hast du das Problem mit den doppelten Tastendrücken nur im VDR oder auch in KODI?

Falls es nur im VDR auftaucht, kannst du dessen Repeat-Filter hochdrehen - in den Einstellungen -> Sonstiges -> "Fernbedienung Wiederholungsverzögerung (ms)" auf ca. 350 ms setzen (mit dem Wert kannst du ein bisschen spielen). Der Hintergrund ist, dass viele RC-5 und RC-6 Fernbedienungen den IR-Frame bei einem Tastendruck ein paar Mal senden (meistens 3x, aber das kann variieren) und da die Wiederholungen ca. 110 - 115 ms auseinander liegen, muss man den Wert so lange hoch drehen, bis unabsichtliche doppelte Tastendrücke weg sind.

davie2000 schrieb:

Hier die Fehlermeldungen - leider nur als Bilder.

Man könnte ja auch eine SSH-Verbindung nutzen

Aber das sieht in der Tat so aus, als ob der nvidia-Treiber vor dem Reboot nicht funktionieren will.

davie2000 schrieb:

Ich hatte aber vorher schon neu installiert (Ubuntu geht ja in ca. 15 Minuten) und trotz einer Fehlermeldung von ansible (bzgl. nvidia) habe ich nach Reboot ein Bild, aber keinen Ton

Weißt du eventuell noch, was in der Fehlermeldung stand? Ggf. muss man den installer noch ein zweites Mal aufrufen, wenn vor dem Reboot der nvidia-Treiber nicht erfolgreich geladen werden konnte, damit die automatische Erkennung des 50Hz-Modul klappt.

Zum Ton: du kannst im VDR-OSD das pulsecontrol-Plugin nutzen, um die Audioausgabe zu konfigurieren. Normalerweise genügt es unter "verschiebe Wiedergabe" den gewünschten Ausgang zu wählen.

davie2000 schrieb:

die Startzeit vom Reboot bis zum Bild ist super schnell < 1 Minute

Zeig mal die Ausgabe von systemd-analyze blame und systemd-analyze critical-chain, vermutlich kann man mit einer statischen IPv4-Addresse und deaktivertem DHCP für IPv6 noch einiges rausholen.

davie2000 schrieb:

aber seit Umstellen auf den Skin osd2web (via OSD) geht die Fernbedienung nicht mehr

Damit trittst du die Kontrolle an osd2web ab - das bietet auf Port 4444 das Webinterface an und nachdem man sich ein Theme ausgesucht hat, gibt es unten links ein Knöpfchen, mit denen man eine Ferbedienung einblenden und das OSD aufrufen und steuern kann.

Wenn man das nicht über osd2web zurücksetzen will, kann man man den VDR mit systemctl stop vdr stoppen, dann in der /var/lib/vdr/setup.confden Wert OSDSkin = lcars setzenund startet den VDR wieder mit systemctl start vdr starten.

Oder man nimmt dbus2vdr, während der VDR läuft: vdr-dbus-send /Skin skin.SetSkin string:'lcars'

davie2000 schrieb:

allerdings gibts nach Aufwachen (auch sauschnell) "buntes Schneegestöber" - die Konsole geht aber

Standby habe ich noch nicht ausprobiert und Skripte, die den VDR vor dem Standby stoppen oder die DVB-Treiber neu laden lassen, gibt es noch nicht - die müsste noch jemand erarbeiten.

davie2000 schrieb:

Wie kann man dich/euch dabei am besten unterstützen (wenn man kein großer C++ Programmierer ist)?

Ich bin kein großer C++ Programmierer, nach Möglichkeit bleibe ich bei Shell-Skripten und Python - halt überall da, wo man um die Geschwindigkeitsvorteile von C++ herum kommt ...

Es sollte genügen, wenn du die Einträge für ppa:yavdr/main aus der Konfiguration von apt entfernst, also /etc/apt/sources.list.d/ppa_yavdr_main_bionic.list (oder meinetwegen auch alle Dateien in /etc/apt/sources.list.d/) entfernst.

Schau mal, ob dir dieser Patch hilft: [gelöst] VDR 2.3.9 hängt bei der Wiedergabe von Aufnahmen mit rpihddevice

Das ganze gibt es jetzt auch als Paket yavdr-hardware-ps3remote in den Paketquellen (ich habe die udev-Regel so abgeändert, dass das name-Attribut statt der IDs genutzt wird). yavdr-remote hat auch ein Update bekommen, da habe ich die defekte udev-Regel für die PS3 Remote entfernt.

wannseheichwas schrieb:

Ich dachte allerdings die Fernbedienung wird wie eine Tastatur behandelt und würde ootb funktionieren. Wie gesagt, mit evtest werden die Tasten „Remote.conf“ - konform angezeigt.

Ja, aber es gibt zwei Probleme: zum einen generiert die Fernbedienung keine Wiederholungs-Events für gedrückt gehaltene Tasten (das kann der X-Server kompensieren) und zum anderen nutzt sie Tasten, die der X-Server nicht abbilden kann. (wenn sie einen Tastencode >255 haben, wie man iin https://github.com/torvalds/li…linux/input-event-codes.h nachlesen kann). Deswegen der Umweg über ps3remote, das als Adapter zu eventlircd fungiert - es öffnet das Eingabegerät exklusiv, liest die Events aus, fügt Wiederholungsevents ein und gibt die Tastendrücke über uinput so aus, dass eventlircd damit gut zurecht kommt und von dessen Lirc-kompatiblen Sockel lesen dann der VDR und KODI.

In yavdr-ansible fehlt bislang noch das Python-Skript ps3remote (unter yaVDR 0.6 stammte das aus yavdr-base), das die Tastendrücke vom Kernel Input Device in von eventlircd verwertbare Events umsetzt. Was du aktuell siehst, sind vermutlich die Input-Events <255, die vom X-Server an den VDR weiter gereicht werden.

Ich habe das Skript schon auf Python3 umgestellt, das muss als /usr/bin/ps3remote abgelegt und ausführbar gemacht werden: ps3remote.py.txt

Als zusätzliche Abhängigkeit benötigt es das Paket python3-evdev.

Die Systemd-Unit dafür sieht dann so aus:

Die udev-Regel, die die Systemd-Unit startet, sollte dann so aussehen (die vorhandene Version aus dem Paket yavdr-remote einfach überschreiben):

Von eventlircd wird dann die ps3remote.evmap genutzt, um die Tastendrücke auf den yaVDR-Standard zu bringen: https://github.com/yavdr/yavdr…ventlircd-names.rules#L50

Vielleicht kannst du das mal bei dir ausprobieren (insbesondere, ob die udev-Regel greift, sonst man mit udevadm info --query=all --name=/dev/input/eventXX (das XX durch die tatsächliche Nummer für das Gerät ersetzen) nachsehen, was das für udev-Attribute bei dir hat.

Wenn das so passt, kann ich es ein Paket dafür schnüren und es von yavdr-ansible mitinstallieren lassen.

Gefühlt fehlt da bei den Options noch die Mount-Option _netdev und ich würde WantedBy=multi-user.target setzen und dann die Mount-Unit neu laden und reaktivieren:

Nur Dateien in /etc/ werden in Debian-Paketen automatisch als Konfigurationsdateien markiert.

Anpassungen für Systemd-Dateien kannst du in /etc/systemd vornehmen, vgl. den einführenden Abschnitt von https://www.freedesktop.org/so…emd/man/systemd.unit.html

Du kannst also einen Ordner /etc/systemd/system/vdr.service.d anlegen und in einer override.conf folgendes Eintragen:

Bei yaVDR 0.6 so:

sudo process-template /var/lib/vdr/plugins/menuorg.xml

SHF schrieb:

Ausserdem ist es super simpel, da man auf dem Ausgaberechner nichts installieren oder konfigurieren muss, wenn man Xine direkt verwendet.

Abgesehen von einer selbst gebauten libxine-1.2, die das mmal-Ausgabeplugin behinhaltet, xorg usw. ...

SHF schrieb:

Die Hardwarebeschleunigung sollte auch unter X laufen, oder setzt das die Ausgabe über MMAL auf der Konsole vorraus?

Wie gut das mit einem laufenden X-Server harmoniert, habe ich nicht ausprobiert. Bis gestern hatte ich nicht mal alsa(-utils) installiert, weil es für rpihddevice und KODI nicht benötigt wird.

Wie es aussieht muss ich meinen Post vom Februar revidieren - es gibt seit 2014 ein Ausgabeplugin für mmal (https://sourceforge.net/p/xine…ideo_out/video_out_mmal.c) aber das scheint in Distributionen wie Rasbian oder Arch Linux ARM nicht mitgeliefert zu werden. Man muss die xine-lib-1.2 mit --enable-mmal konfigurieren, damit das gebaut wird wird.

Mit xineliboutput und vdr-fbfe -V mmal -A alsa (ggf. noch -E um CEC zu deaktivieren) bekommt man dann Bild und Ton über eine USB-Soundkarte (wie man Ton vom Hardware-Decoder über HDMI oder den eingebauten analogen Anschluss bekommen kann, habe ich noch nicht herausgefunden, vermutlich wurde das nicht implementiert). Hardwarebeschleunigtes Deinterlacing scheint auch nicht möglich zu sein.

Bei der Konfiguration für xine musste ich einige Anpassungen vornehmen, damit die Fehlermeldungen über zu kleine Werte für die Buffer und Frames verschwinden:

Das Abspielen von Videos über den "Medien" Eintrag scheint nicht sauber zu funktionieren, die Videos ruckeln z.T. spürbar (ich habe mit dvbcut erstellte MPEG2 Dateien und eine mkv mit BluRay-Video ausprobiert) und spätestens beim Stoppen der Wiedergabe crasht der VDR 2.4.0 ((das Problem habe ich mit aktuellen Versionen von xineliboutput auch mit VDPAU).

Mein erster Eindruck ist, dass das deutlich instabiler als die Kombination aus rpihddevice und KODI ist und mehr Beschränkungen hat.

CKone schrieb:

meinem rpi3b+ vergisst irgendwie täglich die aktuelle Zeit wenn ich ihn länger als eine Nacht vom Netz trenne.

Der Raspberry Pi hat keine RTC und keine Pufferbatterie - wenn man will, kann man das nachrüsten: http://www.raspberry-pi-geek.d…t-fuer-genaue-Zeitangaben

CKone schrieb:

Was mich auch wurdert ist das die Zeitaktualisierung aus dem VDR vom Einschaltkanal ARD HD beim boot nicht funktioniert, oder kann das der VDR nicht am rpi3 oder liegts am MLD?

Ich denke eine Abweichung von 48 Jahren wird der VDR nicht mal eben kompensieren können (und wenn er schon läuft, während der Zeitsprung passiert, versucht er einen Shtudown, weil der User zu lange untätig war). Mit streamdev-client empfängt der VDR die EPG-Daten nur, wenn man einstellt, dass die Filterdaten mit gestreamt werden sollen (was aber nach meiner Erfahrung nicht unbedingt der Stabilität zuträglich ist).

Auf meinem Raspberry warte ich mit dem Start des VDR, bis die Zeit per NTP gesetzt wurde.

Ich bekomme an meinem Haswell-Laptop nur dann auf einem über HDMI angeschlossenen Bildschirm ein Bild, wenn ich den internen Bildschirm in der Grub-Konfiguration abschalte, also sowas setze:

GRUB_CMDLINE_LINUX="video=HDMI-A-2:1920x1080@50D drm.edid_firmware=HDMI-A-2:edid/edid.HDMI-2.bin video=eDP-1:d"

Sonst bleiben beide Bildschirme schwarz (interessanterweise wird aber trotzdem der X-Server erfolgreich mit den Display-Daten aus der EDID gestartet). Hat jemand schon mal erfolgreich mehr als einen Monitor statisch konfigurieren können?

fnu schrieb:

Es gibt natürlich keine Garantien, aber in 98% der Fälle sollte eine Standard edid.bin mit einer EIA Standardauflösung erstmal funktionieren.

In den EDID-Dateien kann ja auch noch eine Beschreibung der unterstützten Tonformate stecken, daher ist das vermutlich für AV-Receiver nicht ganz unwichtig, was da tatsächlich als unterstützt gelistet wird.

SurfaceCleanerZ schrieb:

Vdpau ist ja aus ffmpeg geflogen...

Ich habe bei ffmpeg 4.0 nur gesehen, dass die seit vielen Jahren als deprecated markierte alte VDPAU API rausgeflogen ist - VDPAU wird noch gelistet:

Mit bootchart kann man sich eine graphische Übersicht erstellen lassen, wann die Dienste starten, das ist oft angenehmer als sich zeilenweise durch die Logs zu wühlen (zumindest weiß man dann, wonach man suchen muss).

Nicht epgd.conf.override, sondern epgd.override, vgl. http://upstart.ubuntu.com/cookbook/#override-files - einfach mal die Dokumentation lesen...

Vielen Dank für die ausführliche Zusammenfassung

Weißt du zufällig, wie sich das verhält, wenn man wie von dir beschrieben eine Konfiguration aufbaut und dann andere Bildschirme anschließt? Kann man da ohne Reboot (für den man dann das Laden der EDID ausbaut) die Bildschirme neu erkennen lassen und an die neue EDID kommen? Bei nvidia-GPUs genügt es ja eine xorg.conf ohne Angabe einer EDID zu laden - das wäre praktisch, wenn sich die X-Konfiguration mit Intel-Grafik für yavdr-ansible automatisieren ließe.

speedyrazor schrieb:

I have located the wirbelscan plugin, but it states its for vdr 2.3.8, and I am, by default, on 2.2.0, I am using Ubuntu 16.04.

Instead of using a vdr plugin for an initial channel scan, you could also use w_scan. Just remember to stop all services which are accessing DVB devices before running it.