Es gibt jetzt eine Variable nvidia_legacy im Playbook - wenn man die auf True setzt, dann fügt er das PPA hinzu und passt die X-Server Konfiguration entsprechend an: https://github.com/yavdr/yavdr…d291a1e2a948258e81faf9eba
Beiträge von seahawk1986
-
-
Ich habe gerade mal Ubuntu 22.04 mit dem nvidia-Treiber aus https://launchpad.net/~kelebek…hive/ubuntu/nvidia-legacy probiert - ich musste in der von yavdr-ansible erstellten /etc/X11/xorg.conf noch ein paar Zeilen einfügen, um zu erzwingen, dass er keine ABI-Prüfung für den X-Server macht:
damit scheint es auf den ersten Blick zu laufen - ich könnte mir vorstellen, das als optionale Rolle für das Playbook zu verpacken.
-
Die CPU in dem VDR, um den es geht, ist ein AMD APU A8-7600 mit GCN der ersten Generation. Ist diese GPU in Sachen Bildqualität & VDR-Alltagstauglichkeit konkurrenzfähig zu dem was ich von der Nvidia GT220 gewohnt war
Ich habe nie AMD-Grafikkarten genutzt, aber soweit ich das mitbekommen habe unterstützt deren VDPAU-Implementierung genauso wie beim noveau-Treiber kein Temporal-Spatial Deinterlacing.
Als Randnotiz: das Ansible-Playbook schaut aktuell nur, ob ein nvidia-Paket installiert wurde (https://github.com/yavdr/yavdr…tasks/detect-xorg.yml#L50), aber wenn das ein Metapaket ist, dass den noveau-Treiber installiert, passt dann die von ihm erstellte xorg.conf nicht dazu.
-
skinelchi baut nicht mehr gegen neuere VDR-Versionen (könnte aber vermutlich angepasst werden) - als Ersatz gibt es das neuere vdr-plugin-skinelchihd
-
Ich habe es gerade erfolgreich für jammy bauen können - da hatte ich wohl etwas falsch in Erinnerung. Dann könnte ich die Pakete im vdr-2.6.7 PPA auch für jammy noch mal für arm64 bauen lassen, dann müsste man auch mit einer Ubuntu Server 22.04 arm64 Installation experimentieren können.
-
Im yavdr-ansible gibt es eine Möglichkeit direkt einen "yavdr07-headless" zu installieren.Wie müsste ich das Playbook modifizieren, um einen "yavdr07-rpi-client" zu erzeugen?
Es gibt bislang nur eine Sonderbehandlung, die für einen Raspberry Pi bis zur 3. Generation auf 32-Bit Systemen gedacht ist: https://github.com/yavdr/yavdr…lob/focal/yavdr07-rpi.yml - wenn die entsprechenden Pakete in den eingebundenen PPAs vorhanden sind, sollte es genügen in der tasks/main.yml der Rolle rpi die nötigen Anpassungen an den zu installierenden Paketen und ggf. benötigten Boot-Parametern vorzunehmen: https://github.com/yavdr/yavdr…es/rpi/tasks/main.yml#L17 ff. - da ich keine passende Hardware habe, kann ich das nicht selber ausprobieren.
ZitatWenn ich die verschiedenen Diskussionen richtig verfolgt habe, müsste es möglich sein, das "rpihddevice" durch "vdr-plugin-softhddevice-drm-gles" zu ersetzen, um den Client auf Raspi4 lauffähig zu machen. Dazu ist aber X zu deaktivieren. Könnte ich das nach 1. durchführen?
Ich hattee das vdr-plugin-softhddevice-drm schon paketiert (allerdings bislang nur für die amd64 Architektur gebaut: https://launchpad.net/~seahawk…shed&field.series_filter=), das vdr-plugin-softhddevice-drm-gles (das wäre https://github.com/rellla/vdr-plugin-softhddevice-drm-gles) von rella braucht aber Bibliotheken, die - wenn ich das richtig in Erinnerung habe - erst mit Ubuntu 24.04 vorhanden sind. Außerdem hat das zumindest laut README noch einige bekannte Probleme bei der Ausgabe.
Ich habe das Paket gerade mal in das PPA für den VDR 2.6.7 hochgeladen (https://launchpad.net/~seahawk…shed&field.series_filter=), aber das hat bislang nur Pakete für amd64 gebaut (die Unterstützung für 32-Bit ARM Systeme ist bei Ubuntu 24.04 mit Ausnahme von Ubuntu Core weggefallen, das bedeutet dann auch das Ende der Unterstützung für die alten RPIs 1-3 mit dem vdr-plugin-rpihddevice als Ausgabeplugin - da würden auch einige Pakete nach der Umstellung auf einen 64-Bit Zeitwert nicht mehr ohne Anpassungen bauen). Ich lasse gerade die ganzen Pakete für noble im PPA noch mal neu bauen, damit die auch für arm64 gebaut werden - da müsstest du also mit deinen Experimenten noch warten, bis alles in https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.6.7 durch ist - https://launchpad.net/~seahawk…archive/ubuntu/noble-main enthält schon die nötigen arm64 Pakete.
Außerdem fehlt unter noble noch das vdr-addon-avahi-linker - dadurch funktioniert die yavdr-network Rolle noch nicht, die man bräuchte, wenn man die exportierten Aufnahmen vom Server automatisch einbinden will - ich hoffe, da komme ich morgen oder am Wochenende dazu.
Wie kann ich einen lauffähigen yavdr 7 einfach in einen "-headless" umzuwandeln?
Am einfachsten dürfte es sein die Rolle headless-session laufen zu lassen - die deaktiviert die Systemd-Units für den X-Server, falls die aktiv sind: https://github.com/yavdr/yavdr…ession/tasks/main.yml#L42 und richtet eine headless-Session ein, damit z.B. das automatische Mounten von Wechseldatenträgern mittels udiskie weiterhin funktioniert. Dann ggf. noch das Ausgabeplugin deaktivieren bzw. auf sowas wie das Ausgabedevice vom vdr-plugin-vnsiserver, das nulldevice von dbus2vdr oder das vdr-plugin-dummydevice wechseln.
Gibt es noch weitere Plugins, die auf der einen oder anderen Seite notwendig/sinnvoll sind?
Das hängt davon ab, wie du das DVB-Signal auf den Raspberry bekommen willst.
-
-
-
Wenn du nur Plugins bauen willst, die ein modernes Makefile haben, brauchst du aber eigentlich nur die Entwicklungsdateien (Header, pkg-config Dateien usw.) - die stecken im Paket vdr-dev, das installierbar ist, ohne die Paketquelle für die Quellpakete hinzuzufügen.
-
Wo kann ich jetzt den Quellcode der installierten VDR-Version, die VDR 2.6.1 ist, herunterladen?
Paketquelle für die Quellpakete aktivieren und dann mit apt:
-
Zu viele offene Dateien
Du könntest mal (als root) schauen, welcher Prozess da so viele Datei-Handles offen hat:
Codefind /proc -maxdepth 1 -type d -name '[0-9]*' -exec bash -c "ls {}/fd/ | wc -l | tr '\n' ' '" \; -printf "fds (PID = %P), command: " -exec bash -c "tr '\0' ' ' < {}/cmdline" \; -exec echo \; | sort -rn | head
Wenn das der VDR ist, dann gibt es vermutlich ein Problem beim Schließen der Datei-Handles im Fehlerfall - da könnte man mal mit strace draufsehen, was da genau passiert.
Falls es etwas anderes ist (z.B. sowas wie VS Code, das meint einen Haufen Dateien gleichzeitig beobachten zu müssen), könnte man auch das obere Limit für die file handles im System hochsetzen.
-
Ich denke es genügt, wenn man die Datei /etc/modules-load.d/serial_ir.conf löscht - das macht das Playbook noch nicht automatisch, wenn die Variable serial_ir_device leer ist aber das ist nicht schwer einzubauen.
-
nach dem Neustart hatte ich nur Ton aber ohne Bild.
Da musst ggf. auf den modesetting-Treiber wechseln - in gelöst: yavdr-ansible mit ubuntu 22.04: Playbook gibt bei intel xorg Fehler aus hatten wir das mal durchgespielt, aber ich bin noch nicht dazu gekommen das im Playbook anzupassen.
-
Welche Argumente bekommt denn der VDR bzw. das Ausgabeplugin mitgegeben? vdr --showargs
Und welches Theme bzw. Plugin wird genutzt? vdr-dbus-send /Setup setup.Get string:OSDSkin
-
https://nfs.sourceforge.net/#faq_c6 erwähnt nur bestimmte Dateisysteme (wobei BTRFS soweit ich weiß das auch unterstützt).
Generell könnte ich mir vorstellen, dass es ein Problem der Reihenfolge ist - wird die Samba-Freigabe gemountet, bevor NFS die Dateisysteme exportiert?
Bekommst du irgendwelche Meldungen oder Warnungen, wenn du die NFS exports aktualisierst? sudo exportfs -rav
https://unix.stackexchange.com/a/315690 erwähnt die Möglichkeit das über ein FUSE-Dateisystem als Zwischenschritt zu lösen.
-
Das ist ok aber es soll auch möglich sein die Karte mit 120Hz über DP und Farbraum 420 zu betreiben.
Wird der mode denn von xrandr gelistet? Ansonsten eventuell mal im nvidia-Treiberhandbuch stöbern, ob es da entsprechende Optionen für das Device gibt. Generell mag softhddevice keine "krummen" Bildwiederholraten, die nicht zum Ausgangsmaterial passen - bei 25 bzw. 50 Bildern pro Sekunde im normalen Fernsehmaterial tut man sich da mit 120 Hz schwer.
Im zweiten VDR ist eine gt460 die auch mit 4k läuft. Die Karte kann aber dann nur 30Hz. Wie lässt sich das auf 2560x1440, 50Hz ändern?
Das Playbook nutzt die Vorgaben aus https://github.com/yavdr/yavdr…dr-xorg/defaults/main.yml (die kann man übersteuern, indem man die jeweiligen Variablendeklarationen nach host_vars/localhost bringt und anpasst), um den Modi Punkte zuzuweisen - der Modus, der den Wunschvorgaben am ehesten entspricht, wird ausgewählt - um Fehler durch Skalierung klein zu halten, versucht es dabei standardmäßig mögliche TV-Auflösungen zu nutzen, so dass das Upscaling vom Ausgabegerät übernommen werden kann.
-
Da hatte ich den falschen grep-Befehl eingebaut, der sollte eigentlich nur auf die Major- und Minor-Version matchen - ich habe das mal überarbeitet und entferne jetzt auch ungenutzte automatisch als Abhängigkeiten installierte flatpaks (betrifft vor allem die alten nvidia-Treiber), die sonst nur unnötig Platz verschwenden.
-
xrandr -d :0 sollte dir zeigen, welcher Modus aktiv ist. Das Playbook bevorzugt standardmäßig einen Modus mit 50 Hz (passend zu den in Deutschland üblichen Bildmodi).
Bei Ruckeln würde ich auch immer schauen, welche Bildverschlimmbesserungstechniken der Fernseher noch zusätzlich auf den Eingang anwendet.
-
Ich habe mal eine neue Rolle install-dvb-firmware gebaut, die die Firmware-Dateien von https://github.com/LibreELEC/d…ware/tree/master/firmware installiert. Das mit dem neu Laden der DVB-Module muss ich mir noch genauer ansehen.
-
Oder ist das schon implementiert und hat hier nicht gegriffen?
Es gibt eine alte Rolle, die bislang nur für eine PCI-ID greift: https://github.com/yavdr/yavdr…toinstall-dvbsky-firmware - aber nachdem die damalige dvbsky.net Webseite das Firmware-Archiv nicht mehr ausliefert, wird es auf die Firmware-Dateien aus dem OpenElec.tv bzw. dem LibreELEC dvb-firmware Repo hinauslaufen.
Man könnte die Firmware im Zweifel auch ohne PCI-ID-Prüfung einfach stumpf holen und reinkopieren, sind ja nur 8KB pro Datei.
Das dvb-firmware Archiv von LibreElec hat aktuell ~10 MB - das wäre vertretbar und würde einen Großteil der bislang vom Playbook erkannten Hardware abdecken. Wenn man dann noch dvb_core und die davon abhängigen Treiber neu laden könnte, würde man vielleicht sogar ohne Neustart auskommen, um die Firmware zu laden - da muss ich mal eine Nacht drüber schlafen.