Posts by reibuehl

    dazu entfernt man die Raute vor dem Eintrag für serial-ir in https://github.com/yavdr/yavdr…lob/focal/yavdr07.yml#L42 - hast du das gemacht, bevor du das Playbook ausgeführt hast?

    Nein, natürlich nicht :( Den Teil habe ich dann auch noch missverstanden. Ich dachte, das würde über das setzen von serial_ir: ttyS0 in der host_vars/localhost aktiviert, weil es in der Doku hieß "Die in dieser Datei definierten Variablen übersteuern die Vorgabewerte aus dem Playbook und der group_vars/all.".

    Da dachte ich, dass alles über das setzen von Variablen passiert.

    Die seriellen Empfänger laufen über rc-core (vgl. https://www.yavdr.org/document…entation.html#ir-keytable) und eventlircd liest direkt vom für den Empfänger angelegten Kernel Input Device, lircd bleibt dabei unter yaVDR komplett außen vor und sollte deaktiviert bleiben.

    Mein Empfänger wird irgendwie nicht richtig erkannt: Wenn ich ir-keytable -c -p all -t ausführe (nachdem eventlircd wie in deiner Anleitung beschrieben gestoppt wurde), bekomme ich nur:

    Code
    /sys/class/rc/: Datei oder Verzeichnis nicht gefunden
    keine Geräte gefunden

    Das serial_ir Kernel Modul ist auch nicht geladen. Wenn ich es händisch mit modprobe serial_ir lade, wird es sauber geladen und lädt auch das rc_core Modul mit. Dann ist die erste Zeile der obigen Fehlermeldung weg, aber ir-keytable gibt weiter "keine Geräte gefunden" aus. Sollte der Ansible Task das serial_ir Modul nicht so konfigurieren, dass es automatisch geladen und für das im yaml angegebene Device konfiguriert wird?

    Nach der Ubuntu Neuinstallation ohne X11 lief das Skript erfolgreich durch und ich hab jetzt zumindest mal ein Bild :)


    Leider scheint die Fernbedienung (eine Hauppauge RC5 Fernbedienung mit einem TSOP-Homebrew IR Empfänger an ttyS0 nicht zu funktionieren, obwohl serial_ir_device: ttyS0 in host_vars/localhost gesetzt ist. Eine definition der FB habe ich (mit den vorgeschriebenen KEY_* Namen in /etc/lirc/lircd.conf.d angelegt und auch die lirc_options.conf so angepasst, wie es unter Debian 10 funktioniert hatte. Es wird aber scheinbar kein lircd dafür geladen. Kannst Du mir da noch etwas weiterhelfen seahawk1986 ?

    Ja, das war genau der Satz, den ich falsch verstanden habe. Dann mache ich die Ubuntu Installation einfach nochmal ganz neu. Macht ja jetzt keinen Sinn an dem bereits vergurkten System weiter zu frickeln.


    Brauche ich für suspend eigentlich eine separate Swap Partition? Die Ubuntu Server Installation legt von sich aus ja erst mal keine an. Die würde ich dann auch gleich mit anlegen.

    Nach dem reboot bricht das Skript jetzt hier ab:

    sudo journalctl -xe -u x-verbose@vt7.service gibt das hier aus:


    Ich vermute, das liegt daran, dass auf dem System der Gnome Desktop läuft. Den hatte ich installiert weil es in der Doku hieß, das der X-Server über den Ubuntu Installer konfiguriert werden soll. Da hab ich dann dort das Ubuntu Gnome Desktop Paket ausgewählt. War das ein Fehler?


    Ich hab noch mal einen reboot gemacht, und das Skript nochmal neu gestartet, aber die Fehlermeldung ist wieder die gleiche.

    Danke seahawk1986 , mit dem legacy installer aus dem Link konnte ich Ubuntu installieren. Der neue Installer ist reproduzierbar immer beim anlegen der Partitionen gescheitert, obwohl die SSD komplett leer war (mit gparted gecheckt).


    Nach der Installation habe ich dann das sudo -H ./install-yavdr.sh laufen lassen. Das liefert einen Fehler beim TASK [yavdr-xorg : unload kms drivers]:


    Sollte ich das Skript nochmal ausführen?

    Hallo,


    ich würde gerne mal yavdr-ansible ausprobieren. Leider fehlt unter https://www.yavdr.org/document…ntation.html#installation das Kapitel 1.2.2 zur Ubuntu Server Installation noch. Ich scheitere schon an der Anweisung "wichtig: ISOs für den alternative Ubuntu Server Installer nutzen" in 1.2, da ich unter https://releases.ubuntu.com/20.04/ nur ein Ubuntu Server ISO (https://releases.ubuntu.com/20…4.2-live-server-amd64.iso) finde. Ist das das richtige? Das bootet, scheint dann aber auf ein kompletten Remote Setup Prozess per SSH ausgelegt zu sein.


    Könnte mir da jemand ein paar Tipps geben? Wie ich das System bis zu dem Punkt bringen kann, an dem es dann in der Doku wieder mit Ansible weiter geht? Ziel sollte ein lokaler VDR (kein headless Server o.ä. sein).


    Gruß,

    Reiner

    Ich brauche wegen des Gehäuses irgendwas mit Onboard Grafik, da ich die zweiteilige DVB-S2 Karte behalten will und die keinen 90° Riser zuläßt.


    Da wäre dann eine Intel CPU mit Onboard Grafik wahrscheinlich die beste (einzige?) Lösung.

    Ich hab noch einen älteren yaVDR PC in der Familie zu betreuen, der Momentan noch mit einem miniITX Board mit Intel Atom D525 (nur 32bit) und yaVDR 0.6 (auf Ubuntu 12.x) läuft. Um den Parents Acceptance Factor nicht zu gefährden, sollte das ganze weiter mit yaVDR laufen, aber einmal in neu und schön :)


    Wenn ich die Doku von yaVDR Ansible und Ubuntu Server 20.04 richtig verstehe, klappt das mit dem vorhandenen Mainboard wohl nicht weil das keine 64bit Unterstützung hat. Nach was muss ich mich den Umschauen, um ein gutes, passendes miniITX Board zu finden, das die passende Onboard Grafik für yaVDR (vdpau) hat? Gibt es da bestimmte CPU/Chipsatz Kombinationen?

    Jetzt muss ich doch nochmal was nachfragen: Als ich gerade versucht habe, auf die gleiche Weise das vdr-plugin-skinflatplus zu bauen, bin ich an der Build-Dependency libfreetype-dev gescheitert. In Debian gibt es nur ein libfreetype6-dev und in den yavdr Repositories experimental-main und experimental-vdr habe ich das auch nicht gefunden. Hast Du mir einen Tipp, wie ich da dran komme?

    Vielen Dank seahawk1986 ich hab das gerade mal mit dem Beispiel versucht und konnte eine ganze Menge deb Pakete bauen. Was mich etwas verwirrt, ist dass bei Deinem Beispiel ein graphlcd-base*.dsc verwendet wird, am Ende aber ein graphlcd-tools*_i386.deb raus kommt. Ist das so richtig oder sollte da (auch?) ein graphlcd-base*_i386.deb entstehen?


    Bei den entstandenen *.deb sind auch lib*-dbgsym Versionen mit dabei. Brauche ich die auch, um dann weiteres zu bauen oder reicht es, die lib* und lib*-dev Varianten zu installieren?

    Was mir beim Versuch, die entstandenen deb Pakeges zu installieren auch noch aufgefallen ist, ist das wohl noch mehr fehlt. libserdisp1 scheint das nächste zu sein. Das währe dann https://launchpad.net/~yavdr/+…field.series_filter=focal ?

    Hallo,


    kann mir jemand eine Anleitung empfehlen, die erklärt, wie man Plugins für die Debian 10 VDR Version baut? Ich bräuchte ein Plugin, das leider weder im e-tobi noch im Standard Debian Repository verfügbar ist (vdr-plugin-graphlcd).


    Gruß

    Reiner

    Hallo,


    ich versuche gerade einen meinen VDRs neu aufzusetzen. Bisher lief der mit yavdr, jetzt soll ein Debian Buster drauf. Da ich meine Aufnahmen zentral auf einen Backend VDR mache, hatte dieser Client bisher immer sein Video Verzeichnis per NFS vom Backend gemounted. Unter Debian Buster schaffe ich es aber bisher nicht, dass das Verzeichnis zum korrekten Zeitpunkt bereit steht.

    Beim alten System hatte ich das Verzeichnis einfach in der /etc/fstab stehen:

    Code
      192.168.1.2:/video /video       nfs             defaults,rsize=8192,wsize=8192,soft,nolock,noatime      0       0

    Unter Debian Buster wurde der Eintrag beim booten allerdings ignoriert, ich konnte aber manuell mounten und dann lief der VDR auch (Zugriffsrechte für den VDR User stimmen). damit systemd das Filesystem automatisch beim booten mounted habe ich die Zeile nun so angepasst:

    Code
    192.168.1.2:/video /video       nfs             defaults,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,rsize=8192,wsize=8192,soft,nolock,noatime      0       0

    Damit wird jetzt zwar automatich das /video gemountet, jetzt started aber der vdr nicht mehr mit dieser Fehlermeldung:

    Ich dachte zuerst, das wäre eine Race Condition und hab die Debian vdr.service mit einem Override erweitert damit auf das remote-fs.target gewartet wird, aber das hat auch nichts gebracht:

    Code
    [Unit]
    After=remote-fs.target
    Requires=remote-fs.target

    Hat jemand hier eine Idee, an was es liegen könnte?


    Gruß,

    Reiner


    [Update:]

    Wenn ich nach dem booten einmal in einer shell mit cd in das Verzeichnis gehe, läßt sich danach der VDR mit systemctl restart vdr korrekt starten!

    davie2000 siehe weiter oben... die 10xSATA müssen nicht alle auf dem Board sein, Was fehlt wird mit ein bis zwei PCIe SATA Controllern nachgerüstet, daher mein Wunsch möglichst viele PCIe Slots zu haben.


    Mein bisheriges Mainboard hat leider nur je einen PCIe x16 und einen PCIe x1 Slot und da ist auch noch der x16 Slot mit der Grafikkarte "verbaut". Der Rest der Slots sind leider nur PCI. In einem der PCI Slots sitzt momentan der Promise SATA 300 TX 4 Controller der die größten Probleme macht. Daher dachte ich, dass es jetzt wohl an der Zeit ist alles neu zu machen anstatt nach einem antiquarischen PCI SATA Controller oder einer PCI Grafikkarte zu suchen um den PCIe x16 Slot frei zu bekommen und dann ein paar Monate später doch vielleicht ein neues Mainboard kaufen zu müssen.

    Ein Server Mainboard wird doch sicher kein SATA benutzen, und zehn Festplatten klingt unsinnig.

    Was klingt bei einem Server an zehn Platten unsinnig? Zwei 1TB SSDs als RAID1 für Boot/Root/User Homes und dann je zwei RAID5 mit 4x2TB für den Rest.

    Das ganze sitzt in einem 19" Rack Gehäuse im Server Rack. Muss ich Bilder schicken, damit man mir glaubt, was die Ausgangslage ist? ||

    Ich habe jetzt mal noch ein paar Stunden mit den Filterfunktionen auf heise.de/preisvergleich gespielt (die leider keine Suche ohne Vorauswahl eines Sockels zulassen :(

    Demnach wäre wohl ein Mainboard auf Basis des Intel C422 Chipsatzes (Sockel 2066) wohl das, was meiner bisherigen Vorstellung am nächsten kommt.