Octopus Net im Zusammenspiel mit TVHeadend

Was sollten die Jungs von Digital Devices denn dann verbessern? Ich dachte immer TCP wäre die Lösung.
Habe eben nochmal eine Mail von DD bekommen:

Zitat von DD

Der Kollege meinte, dass das Problem auch an den Quality of Services Einstellungen im Netzwerk liegen könnte (evtl. Router, Netzwerkkarte oder Clienteinstellungen).

QOS habe ich schon rauf und runter konfiguriert. Das bringt null. Sobald ich durch nen Dateitransfer etwas Last auf das Netzwerk gebe, fängt mein Sat->IP Stream an zu zicken.
Ich wollte bei meiner Octopus eigentlich bleiben. Aber das Netzwerk muss auch irgenwie konfigurierbar bleiben ohne überall ne 2. Karte einzubauen etc.

Zitat von mam

Dieses Digizeuchs ist mit der heißen Nadel gestrickt, zum Anschauen reichts ja meistens noch, aber fehlerfreie Aufnahmen damit kannst Du vergessen.

Seit dem Update (vor einem Jahr) funktioniert das tadellos, auch in schlechten Netzwerken.

Zitat von mam

Ich verstehe auch nicht recht, warum ihr hier so nach "TCP" giert, das macht ersmal nix besser, es kommt nur im Fehlerfalle zu mehr Stottern, da auf die Wiederholung gewartet wird

Richtig, alternativ hast du eben ein nicht ansehbares Bild. RPi hinter 3 Routern -> IMMER grün im Bild, TCP an keinerlei Probleme (oder die originale FW von der DIgio nehmen die kann das auch so).

Zitat von mam

ansonsten wirds nur noch schlimmer durch TCP

Das stimmt schlich nicht, es ist sicherlich keine Traumlösung aber auf dem RPi z.B. war vorher nicht mal ansatzweise ein flüssiges Bild möglich, danach kein sichtbarer Fehler.

Zitat von d00dl3

QOS habe ich schon rauf und runter konfiguriert.

Jap das bringt nichts oder wenig, im Falle des RPi werden die Pakete auch zusätzlich am RPi fallen gelassen und nicht nur vorher.

Technisch nicht möglich ... ja ne, sollen sie bei Inverto anrufen und fragen wie sie es geschafft haben bei der Box die 1/3 kostet (die hat kein TCP und geht trotzdem durch Paket shuffeling - was auch immer das sein soll). Wie RTP/TCP funktioniert könnte man sogar bei Minisatip nachgucken, das kann es ja auch hervorragend. Sollen sie sagen das es ihnen egal ist das der Fehler besteht, dann kann man sich wenigstens darauf einrichten.

könnte bestimmt gehen, wenn man das Paket dhcp3-server unter LE zum Laufen bekommt, ne zweite Karte anschließt und nen Kabel verlegt. Wenn ich LE aber dann update, werde ich den DHCP Server nochmal neu einrichten müssen?Ich finde das schon einen heftigen Workaround aber machbar sicherlich.
Ich würde es erstmal unter Debian/Ubuntu testen und dann bei Erfolg auf LE versuchen.

Ich habe nochwas anderes getestet:
Beebox mit TVH an den Switch vom Octopus. Somit läuft der Sat-Ip Stream exklusiv über den Switch der Ocotopus.
Ich habe dann mal richtig Traffic auf das Netzwerk gegeben. Und siehe da, die Aussetzer haben sich minimiert bzw. sind nahezu komplett verschwunden. Jetzt verstehe ich die Welt nicht mehr. Macht der Ocotopus Switch irgendetwas anderes als mein Netgear Managed Pro Safe Switch

Das mit dem DHCP würde sicherlich gehen, aber das wäre extremer Aufwand und ob das stabil läuft ist auch nicht abzusehen.
Mit der extra Verkabelung würde man ja eigentlich das ganze Konzept Sat>IP aushebeln um den Fehlern der Octopus bei zu kommen.

Ich würde an den Switch von der Octopus einen Nuc/BeeBox/Odroid_C2 dran hängen da drauf Tvheadend + Sat>IP Server oder Minisatip spielen und den als Server betreiben. Das sollte ja klappen ohne Fehler - hofft man.
Somit wird nach außen die Octopus hinfällig und man würde nur noch den Tvh/Minisatip Server sehen. Zusätzlich könnte man die Verschlüsselung direkt entfernen somit bleiben bei den Clients keine Probleme mehr übrig.

Ich habe auch Errors in allen 3 Bereichen , aber die treten bei mir jetzt meist nur noch beim zappen auf. Dort merke ich diese nicht. Wenn der Stream mal läuft, läuft er.

Ich denke die einzigste Option ist noch zwischen Octopus und TVH-Server eine separate Verbindung hinzubekommen. Ohne gleich alle Clients mit DHCP Servern auszustatten.
Ab TVH-Server ist die Verbindung ja wunderbar. Wir müssen es nur schaffen den Sat-IP Stream unbeschadet an unser TVH zu übertragen.

Halten wir fest, der Switch in der Octopus ist schrott wenn er noch nicht mal zum Nachbargerät funktioniert.

Dann müsste man mal probieren

wenn das nicht geht wäre die Octo ja broken by design bzw HW defekt

so wie auf dem Bild hatte ich es bisher immer eingerichtet und so sollte es auch sein.Nur so geht es definitiv nicht. Ist bei mir viel schlimmer als über den Octo Switch.
Theoretisch bräuchte wie schon erwähnt der Octo und die TVH-Box eine eigene Verbindung bzw. eine Verbindung welche nicht durch andere Pakete gestört werden kann.
Meine Idee wäre mit einer 2. Netzwerkkarte den DHCP Server bzw. Router auf dem TVH-Server zu installieren. Oder habt ihr eine Bessere Idee?

Zitat von pacoma

es müsste so sein, wobei ein sep. Netzt zwischen der OCTO und dem KODI / TVH sein müsste.

genau das ist auch meine Idee, dann bräuchten wir dort nur einen eigenen DHCP-Server. Nur wie kommen dann die TVH Clients auf dieses eigene Netzwerk ohne wiederum separate Netzwerkkarten anzustöpseln. Wir drehen uns mit dieser Lösung irgendwie im Kreis.

Zitat von pacoma

Wobei ich dann auch gleich zu Win wechslen kann und das ganze via DVBViewer umsetzten kann, so wie @mam das auch gemacht hat.

mit DVB-Viewer sollte es doch zwischen Octo und DVB-Viewer zu den gleichen Paketverlusten kommen?

Zitat von mam

Das ist reiner Quatsch, vielleicht taugt ja euer Programm nix, oder dieser Nuc ist einfach zu schmalbrüstig um so viele Clients zu bedien, oder...

Tvh, VDR und DVBViewer sind also Schrott Programme ... ja ne is klar. Mein J1900 langweilt sich bei 8 Tunern - CPU ist sicherlich nicht das Problem. Wenn UDP Pakete verloren gehen während des Transportes dann ist das ein Problem, wenn Pakete noch nicht mal zuverlässig durch einen Switch durch kommen ist da etwas extrem faulig. Am Sat>IP Protokoll liegt es nicht weil sonst hätten alle anderen das selbe Problem.

Zitat von mam

Der gehört genau auf den TV Server, und man braucht nur einen davon.

Der DHCP Server ist in der Regel im Router - alles andere wäre extrem untypisch. Wenn alles normal funktioniert brauch man auch nirgendwo einen anderen.

Zitat von pacoma

müsste man dann auf LE verzichten und ein "richtige" Linux nehmen, und muss ja noch die kommunikation zwischen Lan 1 und Lan Octo lösen

nicht wirklich, du brauchst ja nur beide LAN Karten eine IP vergeben (evtl verschiedene Netze), das bei der Octo wiederholen und "fertig". Das ist natürlich ein toller "hack".

Zitat von d00dl3

mit DVB-Viewer sollte es doch zwischen Octo und DVB-Viewer zu den gleichen Paketverlusten kommen?

Soweit ich gelesen habe ist es das selbe (ich durfte das an meiner Digi R1 auch auf allen Clients bewundern) - die Pakete werden ja auf HW Basis verloren - es hängt nicht an der SW die dann hinten dran hängt.

Mal allgemein, habt ihr mal geguckt ob ihr die selbe Octo Rev habt? Evtl sind da faulige Margen raus gegangen.