Octopus Net im Zusammenspiel mit TVHeadend

  • Kannst du mir mal einen gefallen tun, teste mal bitte die MLD. Brauchst sie nur auf einen USB drauf geben und kannst sie von dort aus starten. Beim Start wählst du SHD-satip aus. Das du mal einen vergleich hast wie schnell und einfach ein Statip eingrichtet ist. Kannst dann auch jeder Zeit Kodi dazu installieren alles per WebIF.

    HTPC: MLD 5.4 64Bit | ASRock Q1900M | 4GB Ram | DigitalDevices DVB-S2 | SSD 64GB | HDD 2,5 500GB | 250GB Backup HDD

  • Ich habe RPi 1/3, Banana Pi mit der MLD mit Satip-Plugin und SatIp-Plugin mit Vtuner und der ONet am laufen

    HTPC: MLD 5.4 64Bit | ASRock Q1900M | 4GB Ram | DigitalDevices DVB-S2 | SSD 64GB | HDD 2,5 500GB | 250GB Backup HDD

  • Das kommt ganz auf den Switch drauf an, wenn ich nur einen Switch im Netzwerk habe geht es bei mir auch (digi r1) ohne Probleme. Sobald 2 Switches drin hangen ging es nicht. Mit aktivierten rtsp tcp geht es dann wieder. Mit der originalen Firmware klappte das schon immer da die irgend einen Puffer hatte. An PC Hardware hab ich das aber noch nicht erlebt. Klingt fast so wie ein Produkt Problem.

  • Mit der originalen Firmware klappte das schon immer da die irgend einen Puffer hatte.

    Der Puffer nennt sich "Quality of Service" und "Flow Control". Leider müssen dann ALLE Geräte das können, es reicht schon aus, wenn einer rumspinnt und nicht darauf reagiert.
    Bei billigen Switchen ist das Feature meist nicht vorhanden, wenn sie gnädig sind, erlauben sie noch einen "Pass Through".
    Bei aktuellen Windows Versionen ist QoS eigentlich immer an, Flow Control muss von Hand aktiviert werden.
    Und bei Linux herrscht das übliche Chaos, weil jeder sein eigenes Süppchen kocht. Hier hilft also nur nachforschen (und manchmal erleben müssen, dass aus Spargründen der Kram nicht seinen Weg in den Kernel gefunden hat).
    BSD Varianten sollten alles out of the Box sauber beherrschen, wobei Flow Control auch meist deaktiviert ist (aber auf jeden Fall vorhanden).

    Das Ganze ist also ein lustige Lotteriespiel und was bei dem Einen funktioniert, muss woanders noch lange nicht gehen.

    Deshalb meine, zugegebermassen brutale, "Lösung", die jegliche Fehlerquelle ausschliesst.

  • Der Puffer nennt sich "Quality of Service" und "Flow Control".

    Nein - irgendwas anderes (hab vergessen was das war) - der in der DIgi R1 die Funktion gewährleistet auch an dump switches. Selbst mit QoS und Flow Control an allen Switches gab es sonst schon Probleme ;) - beim RPi jedenfalls (der nun aber mit seinem gammligen Netzwerkstack nicht das Paradebeispiel ist).

  • Also grundsätzlich liegen zwischen diesem DigiKram und dem ONet schon ein paar Welten. Ich hatte auch erst den Digi, aber der hat meine Testphase nicht überlebt, zuviele Macken an zuvielen Stellen.

    Onet ist da schon im Welten besser...

  • Ich habe zwei switch und die ONet wird auch noch als switch verwendet. Hatte auch schon einen dritten noch dabei und es lief immer ohne Probleme.

    HTPC: MLD 5.4 64Bit | ASRock Q1900M | 4GB Ram | DigitalDevices DVB-S2 | SSD 64GB | HDD 2,5 500GB | 250GB Backup HDD

  • Ich habe zwei switch und die ONet wird auch noch als switch verwendet. Hatte auch schon einen dritten noch dabei und es lief immer ohne Probleme.

    Du kannst auch hundert Switche nehmen, das Problem entsteht durch "Fremdtraffic" im LAN, der sich nicht um die Videostreams kümmert.

    Wenn Du also nur ein oder zwei Rechner dranhast, am Besten nur "Konsumenten", wirst Du kein Problem bekommen.
    Je weniger los ist, desto besser funktioniert Sat-IP (deshalb: "SonnenscheinLAN").

    Hier werkeln so 50 Rechner (und 10 Switche, aber egal) und da machen die Leute schon öfters mal Dinge, die das LAN in die Knie zwingen können.

    Ich hab schon mal vorsorglich neue Kabel eingezogen, bereit für 10Gbe oder gar 100Gbe. Aber bislang sind die Teile ja noch unbezahlbar...

  • @mam


    Workauround kling für mich plausiebel, nur habe ich das Problem, das der eigentliche TVServer (welcher ja dann auch der zusätzliche DHCP werden soll) ein Nuc ist. Somit ist da nichts mit zweiter Lan Karte. Ebesnso sind die anderen KodiKlienten auch nicht ausbaubar. Nur die PC's welche sich in der Domäne befinden hatten die Möglichkeit eine zweite Netzwerkakrte aufzunehmen, nur dann ist ja das Problem nicht behoben. Zudem sind die Nuc alle Linux basierend und die Deomänenrechern alle Windows.

  • Somit ist da nichts mit zweiter Lan Karte.

    Und? wo ist das Problem?
    Warum hab ich hier ganze viele USB- Ethernet"Karten" rumliegen ???
    Die vier Tuner können ja maximal 100Mbit/s zusammenschaffen, da reicht eine USB3 Verbindung locker aus.

  • Hallo zusammen,

    ich habe eben eine Antwort vom Support erhalten:


    Zitat von dd

    Hallo Herr XYZ,


    in der Octopus Net ist eine Implementierung von TCP derzeit nicht vorgesehen, und in der verwendeten Hardware sehr schwer umzusetzen.


    leider sehr ernüchternd.

  • leider gibt es diesen nicht für DVB-C. Wenn ich mal umziehen sollte und es dort nur Kabel-TV gibt, bin ich wieder am suchen.
    Am liebsten wäre mir eine Box die nicht so groß ist, mit wechselbarem Tuner und TVH fähig :)

    Ich hatte es in nem andren Thread schon drüber:

    PCIE-Karte -> zu groß
    SAT-IP -> zumindest beim Octopus, UDP Problem

    als TVH Server hatte ich eh eine separate BeeBox vorgesehen.
    Vllt mit USB-Tunern?

  • ja sehr ... Dann bleibt die um 300% Günstigere Alternative Digibit R1.

    Würd ich gerne mal antesten....

    Hab ich mal (...es gibt ja das Rückgaberecht), rat mal, warum ich mir ein paar OctopusNet zugelegt habe?
    Dieses Digizeuchs ist mit der heißen Nadel gestrickt, zum Anschauen reichts ja meistens noch, aber fehlerfreie Aufnahmen damit kannst Du vergessen. Egal ob im eigenen LAN, oder im bevölkerten.
    Mag sein, dass es inzwischen dafür bessere Firmware gibt, aber die "sporadischen Aussetzer" haben mich wahnsinnig gemacht.

    (ich hab auch noch diverse andere SatIP Boxen der ersten Generation getestet, viele waren baugleich, alle waren Mist)

    Das fängt schon mit einfachen Dingen, wie dem Netzteil an. Aus 12V macht es sich nicht so einfach 13V und 18V, wie der LNB es gern hätte. Aber der funktioniert ja meist auch mit Werten, die in der Nähe liegen (oder auch nicht...).

    Jeder Cent gespart gibt ein paar graue Haare mehr...

    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, anstatt einfach ein paar Klötzchen zu zeigen und weiterzumachen. Klingt erstmal gut, zumal für Aufnahmen, doch dabei vergißt man schnell, dass jedes Stottern einen Puffer belegt, der niemals wieder freigegeben wird (da Echtzeit übertragen wird und auch abgespielt wird). Ihr habt dann also eine Art Timeshift im Speicher. Das geht ein- zweimal gut, dann kriegt die kleine Box dicke Backen und reagiert üblicherweise mit komplettem Abbruch der Verbindung. Also, wenn einer minimale und sehr seltene Störungen hat, ist das ok, ansonsten wirds nur noch schlimmer durch TCP.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!