Unterbrechungen bei SAT-IP Aufnahmen

[helmuel]

Seit langem verwende ich den DVBViewer mit Recording Service und bin sehr zufrieden. Da die verwendeten 4 DVB-S2 Karten langsam  sterben und immer mehr Sendungen gleichzeitig aufgenommen werden sollen, habe ich vor ca. einem Jahr 2 SAT IP Receiver XORO 8100 installiert. Jeder kann 8 Streams gleichzeitig liefern, insgesamt also 16 Transponder. Die Receiver hängen an einem Gigabit Hub mit direkter Leitung zum Aufnahmerechner mit Win10-64 Bit, der derzeit noch auf DVBViewer 6.1.6 /Server 2.1.6 läuft.

(Ich teste allerdings bereits die Version 7 auf einem anderen System, bei dem das folgende Problem ebenfalls auftritt.)

 

Meisstens  läuft alles problemlos. Es kommt allerdings vor, dass manche Sendungen hunderte Fehler haben. Zwar selten und unvorhersehbar, aber die Probleme sind so stark, dass die Aufnahmen unbrauchbar sind.

Wenn das Problem auftritt, werden mehrere Sendungen auf einem Transponder aufgenommen. Dann haben alle Aufnahmen das gleiche Problem. Ich habe schon die Receiver mit Problemen in der Konfiguration testweise abgeschaltet, ebenfalls einen kompletten Xoro, dann tritt das Problem halt auf anderen auf.

 

Heute gab es ein Problem, welches eventuell näher zur Ursache führen kann.

Von 12:00-13:00 wurde auf Phooenix der Internationale Frühschoppen aufgenommen:

phoenix HD 31.01.2021
P:\V2P\V\Video\$Video_Neu\internationaler frühschoppen - Sendung vom 31.01. 12 00 Uhr_#V2_2021-01-31_11-55-00_phoenix HD.ts
Device: SATIP21
EventID: 2909, PDC: 0xF8B00
Timer Name: internationaler frühschoppen - Sendung vom 31.01. 12:00 Uhr
Timer Start: 31.01.2021 11:55:00
Timer Duration: 01:25:00 (85 min. incl. 5 min. lead time, 20 min. follow-up time)
Timer Options: Teletext=0, DVB Subtitles=0, All Audio Tracks=0, Adjust PAT/PMT=1, EIT EPG Data=0, Transponder Dump=0
Timer Source: Search:Internationaler Frühschoppen
Monitoring Mode: None

11:55:00 / 00:00:00 (~ 0,00 MB) Start Recording
11:55:01 / 00:00:01 (~ 0,00 MB) internationaler frühschoppen not running | EventID: 2909 PDC: 0xF8B00
11:55:02 / 00:00:01 (~ 1,28 MB) PID 5261: H.264 Video, 16:9, 1280x720, 50 fps
11:55:02 / 00:00:01 (~ 1,28 MB) PID 5262: MPEG Audio Stereo, 48 khz, 192 kbps
11:55:02 / 00:00:02 (~ 1,28 MB) phoenix persönlich running | EventID: 2908 PDC: 0xF8ADE
11:59:48 / 00:04:48 (~ 436,82 MB) phoenix persönlich running | EventID: 2908 PDC: 0xF8ADE
11:59:49 / 00:04:49 (~ 438,35 MB) internationaler frühschoppen starts in a few seconds | EventID: 2909 PDC: 0xF8B00
12:00:03 / 00:05:03 (~ 459,42 MB) internationaler frühschoppen running | EventID: 2909 PDC: 0xF8B00
12:00:04 / 00:05:04 (~ 459,42 MB) unter den linden spezial not running | EventID: 2910 PDC: 0xF8B40
12:45:06 / 00:50:06 (~ 4946,74 MB) Errors: 2
12:45:10 / 00:50:10 (~ 4951,96 MB) Errors: 2
12:45:14 / 00:50:14 (~ 4957,42 MB) Errors: 2
12:45:17 / 00:50:17 (~ 4961,64 MB) Errors: 2
12:45:21 / 00:50:21 (~ 4967,30 MB) Errors: 1
12:45:25 / 00:50:25 (~ 4973,18 MB) Errors: 2
12:45:29 / 00:50:29 (~ 4979,02 MB) Errors: 2

 

Das lief fehlerfrei bis 12:45:06, ab dann gab es insgesamt >400 Fehler in den restlichen 15 Minuten.

Genau zu der Zeit startete die 2. Sendung auf dem gleichen Transponder:

 

BR Fernsehen Süd HD 31.01.2021
P:\V2P\V\Video\$Video_Neu\Bayern erleben - Einsiedler - Allein ist nicht genug_#V2_2021-01-31_12-45-00_BR Fernsehen Süd HD.ts
Device: SATIP21
EventID: 3894, PDC: 0xF8B32
Timer Name: Bayern erleben - Einsiedler - Allein ist nicht genug
Timer Start: 31.01.2021 12:45:00
Timer Duration: 01:20:00 (80 min. incl. 5 min. lead time, 30 min. follow-up time)
Timer Options: Teletext=0, DVB Subtitles=0, All Audio Tracks=0, Adjust PAT/PMT=1, EIT EPG Data=0, Transponder Dump=0
Timer Source: Web
Monitoring Mode: None

12:45:00 / 00:00:00 (~ 0,00 MB) Start Recording
12:45:00 / 00:00:00 (~ 0,00 MB) quer running | EventID: 3893 PDC: 0xF8B05
12:45:01 / 00:00:01 (~ 0,69 MB) PID 5201: H.264 Video, 16:9, 1280x720, 50 fps
12:45:01 / 00:00:01 (~ 0,69 MB) PID 5202: MPEG Audio Stereo, 48 khz, 192 kbps
12:45:01 / 00:00:01 (~ 0,69 MB) Bayern erleben not running | EventID: 3894 PDC: 0xF8B32
12:45:06 / 00:00:06 (~ 6,70 MB) Errors: 2
12:45:10 / 00:00:10 (~ 11,71 MB) Errors: 1
12:45:14 / 00:00:14 (~ 16,50 MB) Errors: 1
12:45:17 / 00:00:17 (~ 19,93 MB) Errors: 1
12:45:21 / 00:00:21 (~ 24,50 MB) Errors: 1
12:45:25 / 00:00:25 (~ 28,87 MB) Errors: 1
12:45:29 / 00:00:29 (~ 33,28 MB) Errors: 2

 

Das Problem scheint also damit zusammenhängen, das der Media Server manchmal eine weitere Aufnahme nicht in die Reihe bekommt.

 

Die Probleme sind auf dem Testsystem mit dem neuesten DVBViewer ähnlich, aber nicht identisch. Es kann also sein, dass eine Sendung am Hauptrechner mit Fehlern aufgezeichnet wird, beim Testrechner aber fehlerfrei.

Der Hauptrechner hat 4 Kerne, 12 GB Speicher und normalerweise 15-20% Auslastung bei Aufnahmen. Der Testrechner ist etwas schwächer.

 

Kann ich irgendwelche Einstellungen verändern oder welche Logdateien sind für die Problemanalyse nötig ?

 

Vielen Dank schon mal

 

 

 

 

 

 

 

 

[Griga]

vor 4 Stunden schrieb helmuel:

Das Problem scheint also damit zusammenhängen, das der Media Server manchmal eine weitere Aufnahme nicht in die Reihe bekommt.

 

Das Aufnahme-Log meldet Fehler im ankommenden Stream, nicht im geschriebenen. Deshalb liegt die Ursache wahrscheinlich im Netzwerk. Sat>IP überträgt den TV-Stream via UDP. Das ist prinzipbedingt ein unzuverlässiges Protokoll, auch wenn eine weitere Protokollschicht (RTP) etwas davon abfängt.

 

Gibt es entlang dem Netzwerkpfad eine Stelle, wo eine höhere auf eine niedrigere Bandbreite umgesetzt werden muss? Dazu zähle ich auch den Server PC selbst bzw. den darin verbauten Netzwerk-Adapter.

 

[helmuel]

Hallo Griga,

danke für die schnelle Antwort.

nein, es hängt nicht langsamers im Pfad, alles läuft mit 1000 Mbit.

Der Server hat 3 Netzwerkkarten, im Bridge Mode. Eine dieser Karten war direkt ins Dach verlegt, dort ein 5 Port Switch, daran die 2 SAT-IP Receiver.

Seit ungefähr 3 Wochen, als ich den DVBViewer 7 auf den Testrechner installiert habe, geht die SWAT-IP Leitung über den Gigabit-Switch im Keller, damit ich Testen kann.

Keine Änderung (das Problem habe ich schon länger, aber heute erstmals den Zusammenhang mit der 2. gestarteten Aufnahme gesehen.

Sowohl die Kabel unterm Dach wurden erneuert, auch der Switch testweise ausgetauscht.

Der Switch meldet keinerlei Leitungsprobleme.

.

 

[Griga]

Die Bandbreite hatte ich aus folgendem Grund erwähnt:

 

Nach der Umstellung auf einen Router mit schnellerem WLAN, über das der DVBViewer Media Server angebunden ist, hatte ich plötzlich Diskontinuitäten bei Sat>IP, und zwar insbesondere bei einem über LAN an den Router angebundenen DVBViewer-Client. Man glaubt es kaum: Bessere Hardware, schlechteres Ergebnis als zuvor.

 

Nach einer langwierigen Untersuchung stellte sich schließlich heraus, dass die LAN-Verbindung auf 100 MBit begrenzt und das WLAN damit schneller war. Der Server lieferte die TV-Daten nicht als gleichmäßigen Stream, sondern stoß- bzw. pufferweise, so wie er sie von seinem DVB-Tuner bekam, und nutzte dabei temporär die volle WLAN-Bandbreite, um die Daten quasi als "Burst" möglichst schnell loszuwerden. Das stellte den Router vor das Problem, dass sich die Daten in ihm zeitweise stauten, weil er sie nicht so schnell weiterreichen konnte, wie sie kamen. Und da er nicht in der Lage war, ausreichend zwischenzuspeichern, gingen Daten verloren... die Lösung war schließlich, im DMS eine per Tweak konfigurierbare Bremse einzubauen ("Rate Limiting"), die die maximale Server-Datenrate begrenzt, oder anders gesagt, die Daten-Bursts über die Zeit verschmiert.

 

Also manchmal ist weniger mehr... aufgrund dieser Erfahrung würde ich versuchen, die Datenrate der Receiver zu begrenzen, falls möglich. Denn nur mal angenommen, beide schicken gleichzeitig einen Gigabit-Burst an den Hub, was mach der dann? Guckt vielleicht nur noch dumm aus der Wäsche. Man darf nicht vergessen, dass der Server bei UDP (anders als bei TCP bzw. HTTP) null Feedback erhält, also nicht im geringsten weiß, was von dem gesendeten Kram überhaupt ankommt, und deshalb nicht auf Netzwerk-Kalamitäten reagieren kann.

 

[helmuel]

Hallo Griga,

danke für die Tipps.

Ich habe fast alles im LAN, inzwischen mit 1000Mb. WLAN habe ich nur für Notebooks und Tablets, über die wird aber weder DVBViewer aufgenommen noch angeschaut.

 

Inzwischen ist der Fehler reproduzierbar. Gerade läuft eine HD Sendung im Bay.Fernsehen fehlerfrei (mit 1,45 MB/sec). Sobald ich Phoenix HD dazu starte (mit 1,35 MB/sec) kommen die Unterbrechungen auf beiden Streams. stoppe ich Phoenix, läuft der erste Stream fehlerfrei.

Pro Stream braucht es m.E. max 12 MBit. Beim Test der neuen Receiver habe ich auf jeden internen Receiver eine Aufnahme gestartet und alles lief problemlos. Da war auch schon alles auf 1000 Mb.

Ich habe ja genug Receiver, insgesamt 14 im DVBViewer Media Server definiert.

Gibt es die Möglichkeit, den Media Server so einzustellen, dass er immer nur einen Stream pro Receiver aufnimmt ?

 

[helmuel]

Habe noch etwas getestet.

2 HD Sender auf einem Transponder: Fehler tritt sofort auf.

2 SD Sender auf einem Transponder: keine Fehler.

Stoppen einer HD Aufnahme: Die andere Aufnahme ist sofort fehlerfrei:

Starten von 2 HD Aufnahmen auf einem anderen Transponder: Alle Aufnahmen fehlerfrei.

(SATIP1x ist der erste physische Receiver, SATIP2x der zweite).

Also funktioniert es problemlos, wenn vom gleichen physischen Receiver 2 HD Streams von 2 unterschiedlichen internen Receivern übertragen wird.

 

 

 

 

 

 

 

 

[Griga]

vor 7 Stunden schrieb helmuel:

Also funktioniert es problemlos, wenn vom gleichen physischen Receiver 2 HD Streams von 2 unterschiedlichen internen Receivern übertragen wird.

 

Das bedeutet praktisch, dass die Bandbreite pro Tuner im Receiver beschränkt ist, und zwar auf ein ziemlich klägliches Maß.

 

Zu berücksichtigen ist bei deinen Tests und Überlegungen, dass virtuelle RTSP-Geräte im DMS/DVBViewer keine bestimmten physikalischen Tuner im Server repräsentieren. Clients starten mit dem SETUP-Kommando eine Session. Welchem seiner Tuner der Server die Session zuordnet, ist allein seine Sache, außer man erzwingt eine feste Zuordnung mit dem Frontend-Parameter.

 

Wenn der DMS als Sat>IP Client einen zweiten Sender auf einem bereits empfangenen Transponder haben will, regelt er das über die bereits laufende Session, indem er zusätzliche Daten (PIDs) anfordert. Würde er das nicht machen, sondern für den zweiten Sender eine neue Session über ein weiteres RTSP-Gerät starten, bleibt noch die offene Frage, wie der Xoro als Server das handhabt. Der DMS als Sat>IP Server würde mit seiner auf Ressourcen-Sparsamkeit ausgelegten Hardware-Verwaltung nur einen Tuner dafür verwenden. Wenn der Xoro das auch so macht, kannst du nur versuchen, ihm das mit dem Frontend-Parameter zu verbieten.

 

vor 9 Stunden schrieb helmuel:

Gibt es die Möglichkeit, den Media Server so einzustellen, dass er immer nur einen Stream pro Receiver aufnimmt ?

 

Eine Möglichkeit, ein RTSP-Gerät bzw. eine Session pro Sender zu erzwingen (auch wenn sie sich auf dem selben Transponder befinden), wäre, die Sender im Senderlisten-Editor des DVBViewers auf dem DMS-PC als verschlüsselt zu markieren. Vergiss nicht das Speichern der Senderliste, damit der DMS das automatisch übernimmt (macht er ab Version 3.0, zuvor war ein Stopp/Neustart erforderlich).

 

Eine andere Möglichkeit ist, in der svchardware.xml (bei gestopptem DMS!) für jedes RTSP-Gerät eine zusätzliche Zeile einzufügen:

    <entry name="LowBandwidth">1</entry>    

Die Option wurde vor Urzeiten für USB 1.1-DVB-T-Geräte eingeführt, die mangels Bandbreite nur einen TV-Sender gleichzeitig liefern konnten. Wollte man einen zweiten vom selben Transponder sehen, brauchte man noch so einen Schwachstick. Der Mechanismus funktioniert immer noch, auch bei bei RTSP-Geräten, wie gerade ein kurzer Test ergeben hat. DVBViewer und DMS achten dann darauf, dass mit entsprechend markierten Geräten nur ein TV-Sender empfangen wird, niemals zwei, außer es ist der selbe Sender. Für Radiosender gilt die Einschränkung jedoch nicht.

 

Probiere mal, ob dir das weiterhilft...

 

[helmuel]

Hallo Griga,

vielen Dank für die sehr ausführliche Erklärung und auch den Test.

Am einfachsten kommt mir die Lösung mit der LowBandWith vor. Den Parameter habe ich jetzt in alle 14 Receiver eingegeben und daraufhin 2 Aufnahmen auf dem gleichen Transponder gestartet (Bay.Fernsehen und Phoenix). Die werden dann wie von Dir erwartet auf 2 verschiedene Receiver gelegt:

Auch im Xoro werden 2 belegt:

 

Da scheint also alles wie erwartet zu funktionieren.

Eine einzige Besonderheit ist, dass, wenn ich 2 aufeinanderfolgende Sendung am gleichen Sender aufnehme, diese auf dem gleichen Receiver  gestartet werden.

Aber auch das geht erst mal fehlerfrei.

 

 

Jetzt lasse ich es erstmal mit der Einstellung ein paar Tage laufen und schaue ob die Fehler weg sind und nicht noch irgendeine Verschlechterung auftritt.

 

Vielen Dank !

 

 

 

[Griga]

vor 36 Minuten schrieb helmuel:

Jetzt lasse ich es erstmal mit der Einstellung ein paar Tage laufen

 

Schau mal, ob der DMS damit immer sinnvoll reagiert. Das ist wie gesagt eine uralte Option, die lange nicht mehr getestet wurde. In der Hardware-Verwaltung hat sich seitdem einiges geändert. Deshalb bin ich mir nicht sicher, ob sie unter allen Gegebenheiten fehlerfrei funktioniert.

 

[helmuel]

Das mache ich und werde berichten. 

Wäre schön, wenn Du im Code notierst, dass die Option für mindestens einen Benutzer wichtig ist und nicht gelöscht werden soll...

[helmuel]

Hallo Griga,

bis jetzt läuft alles fehlerfrei, werde das weiter beobachten.

Eine Frage noch zur nötigen Bandbreite: Wird der komplette Transponder vom SAT-IP Receiver zum Media Server übertragen oder nur der eine Sender, der zur Aufnahme ausgewählt wurde ? Sowohl in der DMS Status Anzeige als auch am SATIP Receiver wird jeweils max. 1,6 MB angegeben, also ca. 12 MBit maximal.

Und: Gibt es einen Donate Button für Deine super Unterstützung ?

[Griga]

vor 22 Minuten schrieb helmuel:

Wird der komplette Transponder vom SAT-IP Receiver zum Media Server übertragen oder nur der eine Sender, der zur Aufnahme ausgewählt wurde ?

 

Nur die Teilstreams, deren PIDs vom Client angefordert wurden (also Video, Audio usw. des jeweiligen Senders). Sat>IP Server haben einen PID Filter, der vom kompletten Transponder nur den angeforderten Teil durchlässt. Man kann jedoch auch den ganzen Transponder liefern lassen. Wenn du das testen willst, nimm am besten den TranEdit Analyzer, der immer den gesamten Transponder anfordert.

 

vor 27 Minuten schrieb helmuel:

Und: Gibt es einen Donate Button für Deine super Unterstützung ?

 

Nein. Manche, die sich erkenntlich zeigen wollen, kaufen eine zweite Lizenz (siehe hier) oder auch das HbbTV Add On, falls sie es noch nicht haben. Eine steuergünstige Möglichkeit ist ein Briefumschlag mit einer Geldspende an diese Adresse, eventuell mit einem Vermerk, für wen speziell es gedacht ist.

 

[helmuel]

Hallo Griga,

kurzer Zwischenstatus: Die großen Störungen, also mehrere hundert pro Aufnahme sind jetzt weg. Kleinere Störungen gibt es noch ein paar:

Gestern Abend wurden ab 20:15 gleichzeitig 4 Sendungen in HD aufgenommen. Auf 4 unterschiedlichen Receivern meiner 2 physischen Empfänger.

Alle 4 Aufnahmen haben exakt zur gleichen Zeit so ungefähr 10 kurze Unterbrechungen. So, als wenn sich irgend etwas kurz "verschluckt":

 

20:15:47 / 00:05:44 (~ 517,77 MB) Fastnacht in Franken running | EventID: 4138 PDC: 0x2950F
20:15:48 / 00:05:45 (~ 519,46 MB) Rundschau Magazin not running | EventID: 4139 PDC: 0x2958F
21:33:51 / 01:23:48 (~ 8377,39 MB) Errors: 8
21:33:53 / 01:23:50 (~ 8380,81 MB) Errors: 3
23:22:39 / 03:12:36 (~ 19619,69 MB) Fastnacht in Franken not running | EventID: 4138 PDC: 0x2950F

 

Zu der Zeit ist im Windows Log nichts verzeichnet, die Ethernet Leitung ist laut Switch fehlerfrei und auch im Receiver sind keine Probleme ersichtlich.

Die Störungen sind allerdings so minimal, dass ich da erstmal keine Zeit reinstecke.

[mark2019]

Hallo,

 

könnte jetzt deine Festplatte das Problem sein ?

Welche Festplatte wird genutzt ?

[helmuel]

Festplatte ist eher unwahrscheinlich. Habe 4 WD Disks mit je 12 TB, die als Stablebit Drivepool konfiguriert sind. Die 4 Aufnahmen sollte in unterschiedlichen Disks gespeichert werden. Werde aber evtl. testweise versuchen, die Videos bei der Aufnahme auf die Boot Disk zu schreiben, das ist eine SSD.

[Griga]

vor 4 Stunden schrieb mark2019:

könnte jetzt deine Festplatte das Problem sein ?

 

Abwegig. Da müsste schon das Festplatten-I/O das Netzwerk-I/O behindern, um die beschriebenen Errors im Log zu erzeugen. Wenn der DMS nicht dazu kommt, die Daten auf Platte wegzuschreiben, äußert sich das seit DMS 2.1.7.0 anders:

 

Am 26.8.2020 um 17:03 schrieb hackbart:

Ergänzt: Recorder: Loggen von verlorenen Daten, die eintreffen, aber aus irgendwelchen Gründen nicht auf die Festplatte geschrieben werden können. „Lost Data“-Ereignisse erscheinen im Aufnahme-Log (sofern eingeschaltet), und zusätzlich die Gesamtmenge der verlorenen Daten im svcdebug.log, svcrec.log sowie in Email-Benachrichtigungen (siehe hier).

 

Kurzzeitige Fehler können z.B. auch durch ein Flugzeug verursacht werden, das zwischen Satellit und Schüssel durchfliegt, oder eine Lastspitze im Netzwerk oder PC.  Da gibt es einige mögliche Ursachen.

 

[helmuel]

Seit gestern gab es, bei insgesamt 15 Aufnahmen, keine Fehler. Allerdings wurden alle Aufnahmen zu unterschiedlichen Zeiten gestartet.

Mein DMS ist noch auf 2.1.6.1 und soll im März mit dem DVBViewer auf die aktuelle Version upgegraded werden

[helmuel]

So, nachdem nun über eine Woche mit der Änderung gelaufen ist, möchte ich mein Problem als erledigt melden.

Bei etwa jeder 5. Aufnahme gibt es mal 2 - 5 Fehler, das sehe ich als unproblematisch an.

Seit jede Aufnahme auf einen eigenen Receiver läuft, sind die grossen Probleme vorbei.

Vielen Dank für die Unterstützung !