SAT>IP in einer VM

Hallo zusammen,

ich probiere gerade, einen vdr 2.6.0 in einer Debian-12-VM von unserer Diskstation an den Start zu bekommen.
Das funktioniert grundsätzlich auch.
Er hat eine CPU, 4 GB RAM und eine VirtIO-Netzwerkkarte bekommen, mit der er im Heimnetz unserer Fritte hängt.
Da eine VM keinen PCI-Slot für eine SAT-Karte hat, sollte er mit dem satip-Plugin 2.4.1 einen Kathrein EXIP418 anzapfen.
Dieser hängt unter dem Dach neben dem Multischalter und einer 4040, die mit Gigabit am LAN angeschlossen ist.
Auch das funktioniert grundsätzlich.
Im Log steht dazu:
vm-vdr vdr: [772] SATIP: Adding server '192.168.xxx.14|DVBS2-8|KATHREIN SatIP Server 23:B6:CB' Bind: default Filters: none CI: no Quirks: ForcePilot
Wenn man den vm-vdr nur zum Streamen mit dem streamdev-server 0.6.1-git nutzt, funktioniert das auch ohne Probleme.
Selbst mit aktivem EPG-Scan...

Was bisher nicht fehlerfrei funktioniert: Aufnehmen
Da es keine gute Idee ist, das video-Verzeichnis mit in der VM zu haben, gibt es dafür im NAS ein NFS-Share.
Der Eintrag in der /etc/fstab dazu ist:
nas-ds723:/volume2/VM-VDR-Video-SSD/video /video nfs4 soft,rsize=8192,wsize=8192
Auch das funktioniert - der User vdr kann aus der VM heraus darauf schreiben.
Wenn man jetzt eine Aufnahme startet, legt er los und fängt brav mit der Aufzeichnung an.
Nach einiger Zeit kommt dann aber
vm-vdr vdr: [771] SATIP: Detected 1 RTP packet error [device 0]
und
vm-vdr vdr: [803] /var/lib/video/aktueller_bericht/2025-11-21.09.20.24-0.rec: 7 errors
und
vm-vdr vdr: [781] timer 1 (24 0920-1015 'aktueller bericht') finished with 11 errors
Das kenne ich von unserem anderen VDR (in echter Hardware) nicht.
Der hat nur Fehler, wenn das SAT-Signal mal wegen Gewitter o.ä. mies ist.

Eine Suche danach brachte wenig überraschend, dass ich damit nicht alleine auf der Welt bin.
Eine der Empfehlungen war, den Puffer für die Empfangs-Pakete zu vergrößern.
Das geht bei der VM wohl eher nicht, weil dieser schon die maximale Größe hat:
root@vm-vdr:~# cat /proc/sys/net/core/rmem_default
212992
root@vm-vdr:~# cat /proc/sys/net/core/rmem_max
212992

Nächste Idee: Empfang der SAT-Pakete und Schreiben auf das NFS-Share trennen
So eine Diskstation hat ja zwei LAN-Ports, die man an die VM's durchreichen kann.
Also habe ich der VM mal beide Ports zugewiesen.
Beim nächsten Start hat sie sich direkt mal ordentlich verschluckt, weil die virtuellen Interfaces wohl der Reihe nach aktiviert werden.
Und dann die DNS-Einstellungen von LAN 2 = Gastnetz gewinnen, womit die VM wenig anfangen kann.
Abhilfe feste IP für LAN 2 in der /etc/network/interfaces.
Damit startet die VM und bindet auch das NFS-Share auf der Gastnetz-Adresse ein.
Nur das satip-Plugin mag jetzt nicht mehr.
Statt der Ausgabe von SATIP: Adding server kommt jetzt nur noch weiter hinten
vm-vdr vdr: [1037] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD)
vm-vdr vdr: [1037] retrying
Daraus deute ich: das Plugin findet den Server nicht mehr
Also habe ich in der /etc/vdr/conf.d/50-satip.conf mal fest eingetragen
--server=192.168.xxx.14|DVBS2-8|KATHREIN SatIP Server 23:B6:CB
Das quittiert er aber beim Start mit
vm-vdr vdr: [1088] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.xxx.14/ [device 0]
vm-vdr vdr: [1088] SATIP-ERROR: Connect failed [device 0]

Eigentlich wollte ich ja keinen Compiler mehr benutzen...
Allerdings gibt es von dem Plugin inzwischen eine neue Version.
Also habe ich der VM doch das make beigebracht und die 2.5.0 an den Start gebracht.
Aber: leider keine Änderung im Verhalten.

Und jetzt weiß ich nicht mehr weiter.
Frage: Wie bekomme ich das satip-Plugin dazu, sich auf LAN 1 mit dem Kathrein zu unterhalten, wenn es auch noch ein LAN 2 gibt?

Gruß
Claus

Stimmt natürlich - hilft aber am Ende auch nix.
Auch mit Server über LAN 1 und NFS über LAN 2 sind die Aussetzer da.

Gruß
Claus

Backbone ist Gigabit und in der Fritte, in der die Pakete durchkommen, ist auch nix gedrosselt.
Ich habe den Verdacht, dass in der DS das Schreiben auf das NAS-Share die Stream-Pakete vom Server ausbremst.
Ich habe zu Hause noch einen Pi4B rumliegen - mit dem werde ich als Nächstes mal satip mit NFS testen.
Oder mit dem Hardware-VDR und NFS zu localhost...

Gruß
Claus

P.S.: Der --server-String muss in Hochkommas eingeschlossen werden

Nächster Versuch:
Wir haben einen Pi4B, der sich sowieso nur langweilt.
Der darf ja keine wirklich kritischen Dinge machen und ist deshalb nur Backup-Nameserver und Wake-On-Ring-Gateway.
Und schaut alle 10 Minuten nach, ob auch alle Hosts mit Server-Funktion noch da sind.
Das ist ziemlich wenig für so eine Beere.

Also hat er jetzt einen vdr mit remote-, satip- und streamdev-server-plugin dazu bekommen.
Und vdradmin-am zum Steuern - alles per apt-get install aus den offiziellen raspbian-Sources für bookworm.
Ausflug: Es ist schon erstaunlich, an wie vielen Stellen man nach dem Installieren noch händisch was anpassen muss, damit dann alles auch läuft.
Jedenfalls lässt er sich jetzt per streamdev-Server zum Streamen und per vdradmin-am zum Aufnehmen bewegen.
Ziel für die Aufnahme ist wieder ein NFS-Share auf der Diskstation.

Und das Ergebnis ist überaus erfreulich:
pi4b vdr: [12795] timer 4 (27 0650-0725 'Nachrichten') finished with 0 errors
pi4b vdr: [12795] timer 3 (6 0645-0729 'Die Sendung mit dem Elefanten') finished with 0 errors
Mithin 2 parallele Aufnahmen von unterschiedlichen Transpondern vom SAT>IP-Server auf das NFS-Share ohne Fehler!
Das ist für mich ein Ausrufezeichen wert.

Und es bedeutet perspektivisch für uns dann wohl auch das Ende für den Hardware-VDR-Boliden.
Schauen wir mal, wie der Pi sich so auf Dauer als VDR-Basis macht.
Wobei das Schreiben auf ein NFS-Share auf einem anderen Host sicher nicht die endgültige Lösung werden wird.
Der VDR ist ziemlich zickig, wenn er nicht in das für eine Aufnahme vorgesehene Verzeichnis schreiben kann.
Da werde ich wohl eher eine M2.SSD im USB-Gehäuse an den Pi hängen und ihn darauf schreiben lassen.
Syncthing darf die Aufnahme dann danach im Hintergrund auf das NAS schieben.

Gruß
Claus