• Was sagt denn ls -l /srv/vdr/video/video? Ist das ein Symlink oder ein Verzeichnis?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die automatische Erkennung funktioniert folgendermaßen: Er holt sich alle möglichen Modes für alle verbundenen Anschlüsse. Dann sortiert er die Modes nach den Kriterien Refreshrate, Auflösung und Anschluss unter Berücksichtigung der Variablen preferred_refreshrates, preferred_resolutions und preferred_outputs . Der Anschluss mit dem Mode, der da am besten bewertet wird, wird der primäre Bildschirm, der andere Anschluss wird für seinem besten Mode als sekundärer Monitor konfiguriert. Mit der oben gezeigten Anpassung, sollte ein 4k oder Full-HD TV mit einem 50 Hz Mode als primärer Anschluss gewinnen und der beste Mode im Sinne der Vorgaben auf dem zweiten Monitor wäre dann 800x600@75 Hz.


    Wenn man eine Konfiguration fest vorgeben wollte, könnte man das Template für die /etc/X11/xorg.conf.d/20-intel.conf anpassen: https://github.com/yavdr/yavdr…emplates/20-intel.conf.j2

    Ok - hab jetzt mal Deinen Vorschlag eingebaut und er baut die xorg.conf genau so wie gewünscht. Perfekt. Danke...!

  • Nach der Umstellung auf YaVDR ansible (die ziemlich problemlos gelaufen ist - danke an seahawk dafür...!) bleibt aktuell nur eines der bisher vorhandenen Features offen, die momentan den WAF des neuen gegenüber dem Alten ein wenig verschlechtern ;)


    Wie wäre denn der Weg um einen VDR mit zapcockpit Patch zu integrieren, ohne gleich eine komplette Dev-Umgebung auf die Beine stellen zu müssen (und nebenbei noch updatefähig zur restlichen Umgebung zu bleiben)?


    Danke...

  • Für einen selbst gepatchten VDR tut man sich IMHO mit einem eigenen Launchpad PPA am leichtesten ( CKone hat z.B. eines für seine VDR-Pakete mit zapcockpit-Patch angelegt).


    Mit dem yalptool (den python3 Branch habe ich gerade für bionic und focal paketiert) kann man dann VDR-Plugins und andere Pakete zwischen PPAs abgleichen, solange sie sich ans Namensschema halten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • vieleicht stelle ich mich zu blöd an, aber ich finde die Lösung nichtmehr um eine 50p Modeline hinzubekommen, kann mir vieleicht einer kurz helfen, oder gibt es mitlerweile eine einfachere lösung?


    Gruß Andreas

    | HP Microserver Gen 7 | Cine S2 + DVBSky S952 | vdr2.2 | Streamdev Server |
    | Streamdev Clients: paar Rpi2, yavdr.... |

  • cvt kann dir Modelines errechnen: [https://linux.die.net/man/1/cvt]


    Für 1080p50 sähe das z.B. so aus:

    Code
    Modeline    "1920x1080_50"    148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync

    Normalerweise musst du das nur machen, wenn du einen Monitor hast, der die unterstützen Modes nicht korrekt über seine EDID ankündigt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe gerade mal auf github den Befehl endeckt:

    Code
    sudo -H ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-xorg"

    leider läuft der beamer trotzdem auf 60p, auch wenn das script wohl die richtige mode erkannt hat, gibt es auf ansible kein webfront mehr?

    | HP Microserver Gen 7 | Cine S2 + DVBSky S952 | vdr2.2 | Streamdev Server |
    | Streamdev Clients: paar Rpi2, yavdr.... |

  • So wie es aussieht, bekommt er die EDID von deinem AV-Receiver, nicht vom Beamer.


    Wie sieht denn die erzeugte /etc/X11/xorg.conf und die Dateien in /etc/ansible/facts.d aus?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • eine xorg erzeugt er mir leider nicht in X11


    xorg.fact


    | HP Microserver Gen 7 | Cine S2 + DVBSky S952 | vdr2.2 | Streamdev Server |
    | Streamdev Clients: paar Rpi2, yavdr.... |

  • eine xorg erzeugt er mir leider nicht in X11

    Das ist merkwürdig - kannst du dir mal den aktuellsten Stand von yavdr-ansible ziehen (oder die Änderung an der ansible.conf von Hand einbauen) Debug-Ausgabe des Playbooks in eine Datei Umleiten und diese hier posten?

    sudo -H ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-xorg" -v | tee yavdr-xorg.log

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe noch ein spezielles Problem im Umfeld des eingesetzten CAM-Moduls.


    Beim Start schlägt manchmal - nicht immer - die Initialisierung des Moduls fehl. Keine Ahnung woran das liegt oder wer genau da ggf. etwas zur Behebung tun müsste oder könnte, aber in so einem Fall führt ein Neustart des vdr-Prozesses eigentlich immer zu einer funktionierenden Umgebung. Blöd ist das deswegen, weil im Zweifel Aufnahmen fehlschlagen, wenn das nicht funktioniert.


    Im Log sieht das SO aus:


    Kann man (bzw. WIE kann man) das abfangen und in einer solchen Situation den VDR neustarten - ähnlich der Lösung, wo auf den Start der DVB's gewartet wird...?

  • Die wait-for-dvb@.service wartet nicht auf CAMs (weil die nicht jede Karte hat) - versuch mal eine wait-for-ca@.service anzulegen:

    Und die für die deine Karten mit CA zu aktivieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nur zur Sicherheit - sollte es anstatt:

    Code: /etc/systemd/system/wait-for-ca@.service
    ExecStart=/usr/bin/logger -t wait-for-ca git device %i

    nicht (aus der wait-for-dvb abgeschaut) eher:

    Code
    ExecStart=/usr/bin/logger -t wait-for-ca got device %i

    heissen?


    Startet er dann - sofern das fehlschlägt - den vdr-service neu? Da sind mir zugegeben die Zusammenhänge noch nicht wirklich klar...

  • Startet er dann - sofern das fehlschlägt - den vdr-service neu? Da sind mir zugegeben die Zusammenhänge noch nicht wirklich klar...

    Macht er nicht - er wartet nur...


    Ich hatte eben sowas hier:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!