TS-Doctor stört Sat>IP-Streams

Begonnen von no310.spam, September 05, 2017, 22:41:30

« vorheriges - nächstes »

no310.spam

Hallo,

bin neu hier und kämpfe leider seit Umstellung von Enigma2-Boxen auf LAN-basiertes Fernsehen mit einem sehr seltsamen Problem.

Ich empfange Sat-Fernsehen über einen Digibit R1, der die Sat-Signale in Sat>IP übersetzt. Darauf greift dann ein TV-Headend-Server zu, der als TV-Server auf meinem NAS Synology DS-215j läuft. Über das Netzwerk sind dann verschiedene TV-Clients angeschlossen, die den Stream von dort abgreifen.

Der TV-Server speichert Aufnahmen im Format *.ts ab und da ich für alle Clients Timeshift aktiviert habe, wird auch bei Live-TV nur der zwischengepufferte Stream an die Clients geschickt.

TS-Doctor habe ich auf einem Win10-64bit-PC installiert. Wenn ich von dort nun auf Aufnahmen, die auf dem NAS liegen, zugreife und weiterverarbeite, kommt es zu massiven Störungen des Sat>IP-Streams. Aufnahmen analysieren und schneiden führt noch nicht zu Störungen, aber sobald ich die mit Schnittpunkten markierte Datei wieder als neue Datei auf dem NAS abspeichern möchte, kommt es zu Klötzchenbildung bis zum Ausfall im Sat>IP-Stream.

Die Prozessorlast auf dem NAS ist dabei nicht übermäßig. Das durchgängige Gigabit-LAN verträgt die Datenmenge sonst auch problemlos (gleichzeitiges Lesen und Schreiben großer Dateien auf dem NAS ohne TS Doctor problemlos möglich). Es ist auch nicht nur der Stream zum Client gestört; wenn ich eine Aufnahme mache, die ja direkt vom TV-Server auf das NAS geschrieben wird, habe ich dieselbe Klötzchenbildung.

Überall wird immer die neueste Software-Version verwendet; ich halte meine Systeme stets aktuell.

Meine Vermutung ist, dass der TS-Doctor alle TS-Streams im Netzwerk scannt und dadurch auch das Live-TV bei mir beeinflusst wird.
Kennt jemand das Problem oder kann mir Tipps zur Fehlersuche oder gar Beseitigung geben?

Vielen Dank fürs Lesen des langen Textes schon mal...

LG

no310

Mam

#1
Also ersteinmal muß man darauf hinweisen, dass der TSDoc an Deinen Problemen der Unschuldigste ist.

Was Du beschreibst, sind LAN Probleme, die durch nicht-kompatible Hardware, Fehlkonfigurationen und/oder einer Mischung von beiden entstehen.

Das fängt schon an mit dem Digibit R1, ein bekanntermassen nicht wirklich toller Receiver und vor allen Dingen nicht wirklich des unbedingt erforderlichen Qos fähig.

Qos ist "Quality of Service", damit beschreibt man die Fähigkeit, im LAN für eine Verbindung eine bestimmte Bitrate fest zu reservieren.

Für Videostreams ist das lebenswichtig, denn normalerweise gibt TCP/IP einer (der ersten) Verbindung die volle Bandbreite. Kommt eine Verbindung hinzu, gibts erstmal eine Art Schluckauf, danach pendelt es sich so bei 50% für jede Verbindung ein. Usw, Usw. Das Spielchen wiederholt sich immer für jede neue Verbindung (wird eine Verbindung beendet, so wird wieder hochgeregelt und die freigewordene Bandbreite an alle anderen verteilt).

Deine Störungen sind eben diese unvermeidlichen "Schluckäufe", bei ihnen brechen kurzzeitig alle laufenden Verbindungen zusammen, danach wird dann langsam wieder angefahren.

Du kannst das recht anschaulich mit dem Windows Taskmanager (Netzwerkdiagramm) ansehen.

Diese Qos wurde entwickelt, damit bestimmte Verbindungen von dieser Verteilung ausgenommen werden können.
Leider beinhaltet das Protokoll mehr neue Probleme, als es in der Lage ist zu lösen:

a) Qos ist optional, es ist nicht garantiert, dass jedes Gerät es kann und auch jedes Gerät darauf richtig reagiert. Es reicht schon ein Netzwerkteilnehmer (Rechner, Switch, Hub, irgendwas) aus, der es nicht beachtet, schon geht alles in die Hose
b) Qos gibt keine direkten Bandbreiten vor ("ich brauche nun konstant 100Mbit/s"), sondern nur "low", "medium" und "high". Was diese Einstellungen bewirken, wird in jedem Gerät einzeln festgelegt (oder gar nicht, üblicherweise werden alle Switche ausgeliefert mit "medium" für alle Ports)
c) bei "billigen" Geräten ("unmanaged Switch") kann man die Einstellungen nicht ändern, ja noch nichtmals einsehen. Im guten Fall liefern sie die Priorität wenigstens weiter aus, "böse" Geräte löschen den Qos Wert, danach ist dann wieder alles "medium" (und im Eimer)

Es ist extrem schwierig und sehr aufwendig, jede Deiner Komponenten darauf zu testen, ob sie es kann oder nicht.
(die Fehler jetzt zeigen aber schon mal eindeutig, dass entweder eine Kiste nicht mitspielt, oder nicht konfiguriert ist)

So, nach der langen und frustrierenden Einleitung kommen wir zu dem Punkt, wo dann doch wieder die Sonne aufgeht, es gibt eine narrensichere und einfache Variante, um den Kram sicher zum Laufen zu bringen: vollständige Netztrennung!

Du musst also in Deinen TVHeadDingens eine zweite Netzwerkkarte einbauen und NUR DIE mit dem Digibit R1 verbinden (natürlich auch im Digibit NICHTS anderes anschliessen!).
Damit können die beiden auf dieser Verbindung ungestört von allen anderen Daten austauschen, zumindest die Aufnahmen sind damit schon mal gesichert.
Bei Live TV kann es trotzdem noch zu kurzen Störungen kommen, aber die sollten kurz und erträglich sein (jetzt müssen die Daten ja doppelt zu dem Headend, einmal rein vom Digibit, danach wieder raus zum TV Klienten. Durch den Umbau hast Du 50% gespart und so linear sinkt auch die Fehlerrate).

8)

Cypheros

Ich kann Mam mal wieder nur Recht geben. Der TS-Doctor ist nicht im Netz aktiv und scannt einmalig beim Programmstart nach Updates und UPnP-Geräten. Das sollte aber kein Auswirkungen haben. Wenn aber Aufnahmen eingelesen und geschrieben werden, macht er das natürlich mit der maximalen Gewindigkeit, die möglich ist.
Falls Du einen aktuellen Rechner mit brauchbarer Netzwerkkarte und kein QOS eingestellt hast, wird der PC vermutlich den größten Teil der Netzwerkbandbreite schlucken. Die vom TS-Doctor, bzw. dem PC auf dem er läuft, genutzte Bandbreite kannst Du in der Log-Datei ganz am Ende sehen.
Beispiel:
ERRORS : 0
WARNINGS : 0

Speed: 73,0 MBytes/sec
Duration: 00:00:04



no310.spam

Danke für die Rückmeldungen.

Habe mal ein paar Logs durchgeschaut und bin da so bei ca. 35 Mbyte/s im Schnitt. Wäre ja theoretisch noch genug Luft.
Ich werde sowieso den TV-Headend-Server auf ein anderes Gerät umziehen und mal schauen, ob sich was bessert. Vermutlich ja nicht, da ja wohl eher der Netzwerkdurchfluss bzw. mangelndes QoS stört.

Wenn ich Zeit habe, werde ich mal einzeln messen und schauen, welche Geschwindigkeiten sich erreichen lassen. Werde erst mal mein 24-Port-Gigabit-Switch messen...
Bei einem zweiten Netz scheue ich ein bisschen den ganzen Aufwand mit Routing etc. Obwohl mit Zeit und Geld wäre mal eine vernünftige VLAN-Lösung schon aus Sicherheitsaspekten gar nicht so schlecht...

Danke auf jeden Fall für den Hinweis, dass TS-Doctor da nicht ständig TS-Ströme zieht/scannt

Cypheros

ZitatDanke auf jeden Fall für den Hinweis, dass TS-Doctor da nicht ständig TS-Ströme zieht/scannt

Keine Sorge, der TS-Doctor beschäftigt sich nur mit der Datei, die Du momentan geöffnet hast.

Mam

Zitat von: no310.spam am September 07, 2017, 22:08:04
Habe mal ein paar Logs durchgeschaut und bin da so bei ca. 35 Mbyte/s im Schnitt. Wäre ja theoretisch noch genug Luft.

Na ja, das eigentliche Problem ist normalerweise nie die fehlende Bandbreite (da muss man schon ein sehr lahmes WLAN haben), sondern "Schluckaufe", die ich zu beschreiben versuchte.
Jede neue Verbindung haut erstmal gnadenlos dazwischen und unterbricht kurz alle derzeit laufenden. Da die Videopakete per UDP übertragen werden, werden sie in der Phase einfach weggeschmissen und niemals wiederholt. Diese Drops siehsts Du dann als Bildstörungen.


www.cypheros.de