Megasat SAT>IP Server 3 / Tvheadend 4.1.2437

Ich habe übrigens nach wie vor Datenfehler. Das hatte ich in den letzten Tagen schon öfter festgestellt, das ich auch bei einzelnen Streams ab und zu Datenfehler habe. Das geht dann 1-2 Stunden so und hört dann wieder auf.

Im Logfile:

2017-10-26 21:40:52.217 [ TRACE]:satip: RTP discontinuity (4674 != 4675)

Da es sich hier immer nur um ein versetztes Paket handelt, gehe ich davon aus, das es hieran liegt:

https://tvheadend.org/issues/4621

Also das Update auf 4.3-584 sollte man auf alle Fälle irgendwann machen.

Im Gegensatz zu dem hier im Thread beschriebenen Problem mit arte HD / Das Erste bzw. mehreren HD Streams, sind das nur ganz kleine Bildstörungen wenn ein Paket vertauscht ist.

Zitat von Skibi

Nun Maximum PIDs auf 8 und keine Artefakte mehr:

Dabei wird weiterhin nur ein Tuner genutzt.

Was für eine TVH Version nutzt Du? Denn in neueren TVh version ist das geändert worden:

https://tvheadend.org/issues/3903

Das verhalten ist bei Aktuellen Version 4.3.584 dann folgendermaßen: Bei 1 Sender werden 8 PIds übertragen und es kommt der Stream für den einen Sender ca. 10 Mbit je nach Kanal. Beim 2. Sender auf dem gleichen Transponder währen es aber mehr als 8 Pids, so das TVH pids=all überträgt, mit der Folge, dass der ganze Transponder übertragen wird und eine CPU last (zumindest beim XORO) von fast 50%. Wenn das dann auch beim 2 Tunder passiert, das der ganze Transponder übertragen wird, dann ist mein XORO schon bei 90% und das war gar nicht gut.

Das ist aber schon in 4.2 drin, sprich die jetzige stable hat das.

Zitat von CvH

Das ist aber schon in 4.2 drin, sprich die jetzige stable hat das.

Das ist unstrittig. Nur ist das Verhalten dann so, das alle PIDs übertragen werden (8191 steht für alle):

Und die CPU ist bei 50%:

Da die Max. Pids nur für alle zusammen eingestellt werden kann, kommt beim nächsten Programm gleich wieder der Volle Stream:

Die CPU Belastung ist dann beim XORO schon 95%

Beim dritten unterschiedlichen Transponder, versucht er schon 3x 41000 KBits zu übertragen und da schmiert er voll ab und es kommen nur noch Datenfehler. Der XORO zeigt dann auch schon mal 115% CPU an.

Deswegen gehe ich davon aus das es keine funktionierende Lösung ist. Zumindest nicht bei dem XORO. Vielleicht hat der IP Server 3 ja mehr Power?

@oelsi, @Skibi
Könnt Ihr bitte mal testen wie viele Komplette Transponder Ihr mit dem IP Server 3 übertragen könnt? Vielleicht hat der Megasat ja wirklich eine bessere Hardware verbaut. Das wäre wirklich sehr nett, denn noch kann ich den XORO zurückgeben.

Zitat von Skibi

Ich nutze Version 4.4.20170707 auf meiner Synology-NAS.

Nutzt Du das eigentlich in einem Docker Container?

Bei meinem QNAP im Docker funktioniert es nach wie vor noch nicht. Mit einem dedizierten Server mit Librelec und TVH 4.2 läuft es, aber mit dem QNAP und Docker geht es acuh mit der neusten TVH nicht. Ich habe schon versucht die UDP Buffer zu erhöhen (sysctl -w net.core.rmem_max=26214400), aber nach wir vor kommen folgende Fehler:

2017-10-29 18:59:14.133 [ TRACE]:satip: RTP discontinuity (34621 != 34625), queueing packet
2017-10-29 18:59:14.133 [ TRACE]:satip: RTP discontinuity (34621 != 34626), queueing packet
2017-10-29 18:59:14.134 [ TRACE]:satip: RTP discontinuity (34621 != 34627), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34621 != 34629), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, reset sequence to 34622 from 34621
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34621 != 34630), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34622)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, reset sequence to 34624 from 34623
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity (34623 != 34631), queueing packet
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34624)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34625)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34626)
2017-10-29 18:59:14.135 [ TRACE]:satip: RTP discontinuity, requeueing packet (34627)
2017-10-29 18:59:14.136 [ TRACE]:satip: RTP discontinuity (34628 != 34632), queueing packet
2017-10-29 18:59:14.136 [ TRACE]:satip: RTP discontinuity (34628 != 34633), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity (34628 != 34634), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, reset sequence to 34629 from 34628
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity (34628 != 34635), queueing packet
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34629)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34630)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34631)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34632)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34633)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34634)
2017-10-29 18:59:14.137 [ TRACE]:satip: RTP discontinuity, requeueing packet (34635)

2017-10-29 18:59:14.196 [ TRACE]:satip: RTP discontinuity (34662 != 34663), queueing packet
2017-10-29 18:59:14.197 [ TRACE]:satip: RTP discontinuity (34662 != 34664), queueing packet
2017-10-29 18:59:14.197 [ TRACE]:satip: RTP discontinuity (34662 != 34665), queueing packet
2017-10-29 18:59:14.198 [ TRACE]:satip: RTP discontinuity (34662 != 34666), queueing packet
2017-10-29 18:59:14.198 [ TRACE]:satip: RTP discontinuity (34662 != 34667), queueing packet
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity (34662 != 34668), queueing packet
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity, reset sequence to 34663 from 34662
2017-10-29 18:59:14.199 [ TRACE]:satip: RTP discontinuity (34662 != 34669), queueing packet
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34663)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34664)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34665)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34666)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34667)
2017-10-29 18:59:14.200 [ TRACE]:satip: RTP discontinuity, requeueing packet (34668)

Ich bin jetzt etwas weiter.

Wenn ich mit meinem TVHeadend im Docker Container eine Aufnahme laufen habe, und gleichzeitig von meinem anderen Librelec Daten auf eine SMB Freigabe des QNAP speichere, kommen massive Datenfehler. Das passiert nicht wenn ich das von einem Windows Rechner mache.

Die Freigabe habe ich in Librelec so gemountet:

What=//192.168.0.2/Recordings/Kinderfilme
Where=/storage/recordings/Kinderfilme
Options=username=tvheadend,password=tvhead123,rw,vers=3.0
Type=cifs

Ich hatte es zuerst mit vers=1.0 laufen, hab es aber auf 3.0 geändert. Ich denke damit ist das SMB Protokoll 3 gemeint. Aber es läuft immer noch nicht.

Vielleicht hat ja noch jemand eine Idee.

Ich denke ich habe das Problem gelöst. Ich darf den TVHeadend nicht auf dem QNAP NAS Installieren, denn sobald dieser in Kopieroperationen verwickelt wird, kommen die UDP Pakete nicht mehr durch.
Das gleiche Passiert, wenn ich den TVH Server (ohne Docker) Standalone habe und von dem gleichen Server große Dateien kopiere. Trotz Gigabit LAN. Wenn ich aber von dem Standalone TVH Aufnahmen starte (auf den Freigabeordner vom NAS) und im gleichen Netzwerk mit einem anderen Rechner große Dateien auf das NAS kopiere stört sich das nicht.
Deshalb ist TVH im Docker auf dem NAS nicht möglich, da es Probleme gibt, wenn man doch mal etwas mehr kopiert.

Kopieren ist CPU-Intensiv und auch RAM-belastend.
Soll man nicht meinen, aber das ist der Flaschenhals.
Entpacken und schauen war bei mir zB nicht gleichzeitig möglich.
Und gerade beim NAS ist alles meist "gerade so ausreichend". War für mich auch einer der Gründe, warum ich nach diversen NAS-Systemen auf einen eigenen Server umgestiegen bin.

Zitat von mippi

kommen die UDP Pakete nicht mehr durch

"Willkommen" im Sat>IP Land wo das nur durch Sat>IP over TCP zu lösen geht. Das wirst du sehr wahrscheinlich auf allen anderen Geräten auch sehen.
Traffic + UDP sind keine Freunde, alternativ einen separaten LAN Anschluss nur für die Box nutzen der nicht über einen Router geht.

Zitat von don

Kopieren ist CPU-Intensiv und auch RAM-belastend.
Soll man nicht meinen, aber das ist der Flaschenhals.

Nun, den verdacht hatte ich auch. Deshalb habe ich auch etliche Tests gemacht. Ich gebenun nach etlichen Stunden auf und schick das Teil zurück.

Zuletzt habe ich sogar einen neuen TVH auf einem anderen Rechner installiert. Das Ergebnis war immer das gleiche.

Ich kann problemlos 7 Streams aufnehmen, ohne das es zu Datenfehlern kommt. Aber selbst wenn ich nur 2 Aufnehme, und dann gleichzeitig 2 bereits bestehende Aufnahmen über den TVH server schaue (er muss sich ja dann die Daten von dem NAS Server holen und an die Client weitergeben) kommen bei allen laufenden Aufnahmen Datenfehler. Es ist also noch nicht mal nötig, das ich Große Dateien kopiere es reichen schon 2 Streams mit je 12MBits um das SATIP/UDP zu stören. Ich habe echt alles probiert. Der Standalone TVH server ist ein N3150 /1.6 GHz mit GigaBit Lan. Mit den eingebauten DigitalDevices gibt es 0 Probleme.

Für mich ist das Experiment "SAT>IP" erst mal beendet.

Deswegen wird in der Regel auch zur Digibit R1 geraten, die kann als einzige Sat>IP/TCP - alle anderen Boxen fallen an genau der selben Stelle durch.

Zitat von CvH

"Willkommen" im Sat>IP Land wo das nur durch Sat>IP over TCP zu lösen geht.

Ist es möglich zwei TVH mit Sat>IP over TCP zu verbinden, so dass ich die Tuner einfach an einen anderen TVH über TCP weiter leite?

Das "sollte" über Minisatip gehen - ehrlich gesagt nie getestet
Sat>IP Server -> Minisatip Client => Minisatip Server -> Tvh

Zitat von Skibi

Allerdings hat der Digibit nur 4 Tuner

ja das wäre hier natürlich eine Einschränkung

Zitat von Skibi

Dann kann ich mein Quattro-LNB auch nicht mehr nutzen

doch aber gehen halt nur 4 Tuner

Zitat von Skibi

einen Odroid C2 mit Gigabit-Ethernet: er sollte als TVH-Server doch reichen, oder?

ob das mit 8 Tuner reicht ? ehrlich gesagt keine Ahnung ob da irgendwas an das Maximum läuft aber nicht so unwahrscheinlich

Zitat von Skibi

TVH auf einer NAS ist scheinbar keine gute Idee

jein, viel Traffic ist immer der Feind von UDP - das kann dann schon zu viel sein

Zitat von Skibi

Das Thema "PIDs" habe ich gar nicht verstanden

Im Normalfall macht Tvh den ganzen Transponder auf damit du alle Kanäle auf einem Transponder angucken kannst mit nur einem Tuner -> viel Traffic + CPU Auslastung.
Wenn du da die Pids beschränkst auf 6-8?? limitierst du das künstlich. Das kann durchaus schon helfen das Problem zu beseitigen - das wäre auszuprobieren.

Zitat von Skibi

1. Allerdings hat der Digibit nur 4 Tuner
2. Das Thema "PIDs" habe ich gar nicht verstanden: keine Ahnung was das sein soll und was man jetzt für einen Wert in TVH einstellen soll und ob das überhaupt eine Rolle spielt im Hinblick auf die vorher genannten Probleme...

Genau deshalb gebe ich auch auf und schicke das Teil zurück. Ich kann zum Glück noch Widerrufen.
4-Tuner = Zuwenig, der Digibit Verbarucht auch 9-18W. Mein Celeron N3150 (on Board CPU) verbraucht mit 4 Tunern (2 Digital Devices Karten) nur 25W. Ohne Tuner 17W. Dafür kann ich ihn aber auch gleich im "Sportzimmer" zum Kodi Schauen verwenden. Wahrscheinlich hole ich mir eine DigitalDevices 8 Tuner Karte:

https://digitaldevices.de/produkte/dvb-komponenten/max-s8/.

Die verbraucht nur 5w. Dann komme ich auf 22W. Evtl. nehme ich dann noch mal ein Stromsparendes aktuelles Mainboard mit nur 10W, die kosten auch nur 50-80€

Die Karten von DD sind zwar etwas teurer aber Langfristig schont es die Nerven. Mit der Kombination hatte ich nie Probleme, das läuft super.

Les dir am besten noch mal den Thread durch, der hat mir die Augen geöffnet was UDP und SAT-IP angeht:

Octopus Net im Zusammenspiel mit TVHeadend

Vielleicht probiere ich es in ein Paar Jahren noch mal, wenn es HArdware gibt, die SAT-IP über TCP beherrscht.

Bei mir lief die Digi R1 nachdem ich sie auf TCP umgestellt hatte einwandfrei. Aber nur 4 Tuner.

Jetzt habe ich einen alten J1900 und eine 8er TBS6909 für ca270€, das verbraucht um die 25W. Dafür funktioniert sogar mittlerweile transcoding auf der Box.