[Test-Patch] Absturz des satip Server beim EPGScan (Grundig GSS.BOX; Telestar Digibit R1)

Hallo,

ich habe das Problem, dass beim verwenden des satip Plugins (SATIP Server: Grundig GSS.BOX) und eingeschalteten EPGScan der SATIP-Server regelmässig abstürzt. Sobald ich den EPGScan deaktiviere im satip-Plugin, habe ich mit der GSS.BOX keine Probleme mehr.
Das Problem habe ich Klaus Schmiddinger geschildert und einen kleinen Patch geschickt bekommen, der für eine erste Fehlersuche gedacht ist.
Am Wochenende konnte ich das ganze testen und vorerst keine Probleme mehr feststellen, wobei nur mit einen satip-Client (raspberry3) getestet wurde. Vielleicht habe ich auch nicht Intensiv genug getestet.

Zitat

... in eitscan.c mal nach der Zeile

Code

Device->SwitchChannel(Channel, false);

die Zeile

Code

cCondWait::SleepMs(1000);

einfügen.

Vielleicht kann der ein oder andere den Patch mal testen.

Hier noch ein Hinweis von Klaus:

Zitat

Ich werde das aber vorerst noch nicht in VDR einbauen, denn der Fehler
sollte eigentlich dort behoben werden, wo er verursacht wird, also im
SatIP-Server oder im SatIP-Plugin.
Zumindest ist das aber schon mal eine heiße Spur.

Ich werde hier auch weiter testen und hier berichten, wenn der Fehler wieder auftritt.
Vielleicht hat ja jemand noch eine andere Idee, wie man das Problem beseitigen könnte ohne den EPGScan zu deaktivieren.

Gruß,
Uwe

Ich habe leider wiederholt Fehler im Bild. Sobald ein 2. Client hinzukommt (raspberry) gibt es sporadisch, aber regelmäßig Fehler auf beiden Systemen. (Aufnahmen haben auch Fehler)
Eventuell stört noch was anderes?! Was passiert noch bei einen EPG-Scan? PID Scan: was passiert hier? (kann man das eventuell verlangsamen?)

Als nächstes habe ich auch vor, einen kleinen mini satip server zu bauen. Bin gespannt, wie zuverlässig dieser funktioniert.

Gruß,
Uwe

Hallo CvH,

Zitat von CvH

Das könnte aber auch am RPi liegen, durch den sehr bescheidenen Network Stack (Anbindung über USB ...) des RPi werden schon auf Hardware Ebene Pakete fallen gelassen und ab einer bestimmten Menge an Traffic im Netzwerk wird das merklich durch Fehler im Bild.
Das ist (wenn es das ist) kein R1 Problem sondern ein Problem des RPi bzw das Sat>IP über UDP kommt (Octopus und andere haben ja das selbe Problem).

Sobald ich den EPG-Scan deaktiviere funktioniert es ohne Probleme, zumindest mit 1 Stream. Eine Aufnahme auf den Pi3 habe ich noch nicht getestet (2 Satip Devices konfiguriert) Das checke ich nochmal diese Woche. Die Fehler in der Aufnahme sind mit dem Matrix-Board mit 1GBit Netzwerk Schnittstelle (i.mx6 Quad), wobei hier die Netzwerkschnittstelle limitiert ist, zumindest beim Hummingboard, was aber keine Rolle spielen sollte. (Hummingboard: 1000Mbps link is limited to 470Mbps actual bandwidth due to internal chip busses limitation.)

Zitat von CvH

Lässt sich lösen in dem man möglichst Sat>IP Quelle (R1, ...) und RPi am selben Switch hat.
Wenn das nicht geht oder nichts bringt kann man auf die R1 noch die Firmware Mod aufspielen (https://github.com/perexg/satip-axe/tree/master/dist) und dann die Sat>Ip Verbindung via TCP in VDR aktivieren - funktioniert in der Regel gut.

Das teste ich nochmal. Ich hatte mit dieser Firmware nicht so gute Ergebnisse bei der Stabilität, aber ich check das nochmal. Vor allem wegen --> Verbindung via TCP.

Zitat von CvH

Wenn man das alles nicht will/kann (was auch immer) bringt auch Abhilfe wenn man einen anderen Abspieler mit vernünftigen Networkstack nimmt (Odroid_C2 ...).

Mal schauen, sobald es dafür ein AusgabePlugin für VDR gibt, werde ich damit testen. Eine andere Alternative wäre da noch das Asus Thinkerboard oder die neuen Up2 Boards (gibt es ab Ende Mai) ....

Gruß,
Uwe

Hallo CvH,

Zitat von CvH

Wenn die Fehler auf dem Matrix Board sind "sollte" es nicht am Netzwerkstack liegen (Bandbreite ist hier nicht der Limitierende Faktor bei dem UDP Problem) - kann aber immer noch an den Router/Switchen liegen die dazwischen sind -> die UDP Pakete werden dann schon dazwischen fallen gelassen wenn Traffic im Netzwerk ist. Das kann man probieren indem man auf den Switch mal richtig Last gibt (kopieren von großen Dateien) und beobachtet ob die Aussetzer schlimmer werden.

Mhh, ich glaube das Matrix Board scheint vielleicht doch ein Problem mit dem Netzwerk... zu haben. Ich wechsle mit femon auf ein satip Tuner (ServusTVHD). Ich habe nun eine Aufnahme gestartet. VDR nutzt den DVB-S2 (FF-HD-6400)Tuner. DIese wird über NFS auf einem WDMYCLOUD (4TB) gespeichert. Hier gibt es keine Probleme. Der satip-Empfang ist ab jetzt nur noch fehlerhaft. (Ich nutze nur 1satip Tuner und der EPG-Scan ist deaktiviert) Also habe ich aktuell wohl eher ein Problem mit dem Matrix-Board. Ich nutze den Kernel 4.9.5. Ich habe jetzt mein NFS Mount:

mount -t nfs -o v3,rw,soft,nolock,wsize=8192,rsize=16384 192.168.119.222:/nfs/video /srv/vdr/video/

auf das hier geändert:

mount -t nfs -o v3,rw,soft,nolock,wsize=65536,rsize=65536 192.168.119.222:/nfs/video /srv/vdr/video/

Die Fehler die zuvor auftraten, treten nun nicht mehr so häufig auf. Welche Werte sind hier zu empfehlen?

Edit: Eine Aufnahme auf dem raspberry3 (nur 2 satip Devices) nach NFS klappt hier ohne Probleme.

192.168.119.222:/nfs/video on /srv/vdr/video type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.119.222,mountvers=3,mountport=53191,mountproto=udp,local_lock=none,addr=192.168.119.222)

Zitat von CvH

Die FW Mod funktioniert eigentlich sehr stabil - bis auf die Sat>IP über TCP Funktion braucht man die ja heute nicht mehr unbedingt nach dem Firmwareupdate (was ja sicherlich gemacht wurde) auf 1.24.0.156.
Durch das benutzen von TCP ging bei mir alle Probleme weg und das lief auch stabil.

Ich nutze seit heute 1.25.0.156. Die 1.24.0.156 hatte ich nicht genutzt, da sie nicht stabil lief.
Wie kann ich kontrollieren, ob TCP von der gss.box unterstützt wird? (log)

Zitat von CvH

Falls du DLAN einsetzt wäre das auch noch ein Großer "Minuspunkt" für Satz>IP.

DLAN nutze ich nicht. Als Netzwerkswitch nutze ich nun Netgear GS108E-300PES. (Danke für den Tipp an fnu)

Zitat von CvH

RPi, WLAN, mehrere Switche/Router (managed, Plasterouter etc ist egal), DLAN <- das sind so die Sachen die man vermeiden sollte mit Sat>IP.
Bei der ganzen Geschichte ist leider alles kann nichts muss - UDP sei "dank".

Am Switch (GS108E) hängt die GSS-BOX und alle Clients (rpi und Matrix-Board) und meine Fritzbox. Also satip geht nur über den Switch....

Danke für deine Tipps. Vielleicht bekomme ich das ganze doch noch vernünftig ans laufen....

Gruß,
Uwe

Zitat von CvH

Wenn du noch die 1.16.0.120 laufen hattest ist es _normal_ das du keine fehlerfreie Aufnahme hin bekommst - die FW ist einfach nur fehlerhaft.

Ich hatte die Firmware idl4k-1.0.0.146.bin installiert. (von 2015)

Zitat von CvH

Das klingt erstmal gut und sollte keine Probleme machen - leider kann man da keine konkreten Aussagen machen ob das nun einen Einfluss hat oder nicht.

Ich habe mal die Prio von dem Netzwerk-Port des Matrix-Board am Switch auf High gesetzt. Habe nun keine Fehler bei satip, wenn eine Aufnahme stattfindet. Werde das ganze mal weiter beobachten. Auch den EPG-Scan werde ich weiter testen, wenn die Aufnahme Probleme beseitigt sind.

Gruß,
Uwe

Hallo,
die Prio des Netzwerk Ports zu erhöhen, bringt teilweise Besserung, aber dennoch sind vereinzelt Fehler in den Aufnahmen. Fehlerhaft sind nur die Aufnahmen, die mit dem satip Devices aufgenommen werden. Hier wird irgendwie nicht schnell genug weggespeichert?!
Ich muss also erstmal dieses Problem lösen. Entweder ist meine Netzwerkschnittstelle nicht richtig konfiguriert oder NFS fehlerhaft.... Aufnahmen mit der FFHD6400 sind ohne Fehler. Ich werde mal testweise das Netzwerkkabel tauschen. (Kann man Netzwerkkabel auf durchsatz testen?)
Was bedeutet im satip Plugin die Betriebsart: niedrig, normal, hoch und aus.? Edit: habe die Beschreibung gefunden.

Für Tipps wäre ich sehr Dankbar.

Gruß,
Uwe