SAT-IP to LAN Hardware Empfehlung ?

Weil es Thema war. Ich hab den digibit R1 seit vielen Jahren mit satip.axe bei mir und bei Bekannten im Einsatz. Nur nicht auf allen 4 Tunern gleichzeitig ackern lassen, dann ist alles gut. TVHeadend Server nebst icam Patch gestern erst wieder beim Kumpel auf einer alten wetek Play 2 aktualisiert. Den Job macht das Gerät seit Jahren klaglos. Dachboden, Sommer 45 und Winter 3 Grad.

Als Frontend alles nur Erdenkliche im Einsatz. Auf Handy , Tablet, TV Android, TV satip, shield, Playstation, MacBook CoreElec TV Boxen und Amazon Zeugs, etc. Mal mit livetv mit pvrlive, mal als iptv, mal Kodi, mal emby, wie es gerade am besten passt und verfügbar ist.

Achja, nach jahrelanger Abstinenz mal einen octagon surpreme E2 Receiver gegönnt, auch da satip als Client und Server verfügbar, iptv in die Kanalliste einfügbar und somit ein universell einsetzbares Gerät mehr. Als e2 stand alone, satip Server oder Client usw . 4 verschiedene FW mit Multiboot .

Warum schreibe ich das, die Fleiß Arbeit muss halt einmal geleistet werden. Danach nur Erhaltungspflege. Einige negative Erfahrungsberichte liegen imhop im mangelnden Know-how der Benutzer.

Wünsche viel Erfolg mit der neuen Hardware und bin gespannt, wie das Megasat Gerät läuft.

Auf jeden Fall auch den Stromverbrauch messen !

woher hast du ihn? finde das Ding nirgends lieferbar

das hatten wir doch mal vor X-Jahren ... glaube der PvD kann da was genaues zu sagen... waren das IGMP Päckchen die der Switch anständig können muss? Ich habs nur ganz dunkel in Erinnerung. Oder was der Multicast bereich?

i don't know

Eigentlich machen nur gemanagte Switche oder halbmanaged Switche Probleme. Die müssen zwingend IGMP Multicastgruppen können bzw zusammengefasst IMGPv3

Macht das TV-Headend ueberhaupt Multicast ? Das ist doch Unicast.

Bildartefakte heisst doch, das mal ab und zu Pakete verloren gehen. Das hoert sich eher wie schlechte Puffer im Switch an oder so.

Vielleicht kann man ja auch bei Megasat QoS/DSCP oder so konfigurieren ?

Ich mag kein TP Link wenn das der DeBaschdi sieht ...

Kapierr immer noch nicht, was das mit IGMP zu tun haben soll. Wenn ich den TP-Link fred richtig lese, dann scheint der Megasat nicht korrekt kleine Ethernet Datenpakete korrekt auf mindestens 60/64 byte zu taggen, und dann sind die nicht normgerecht und werden vom TP-Link rausgeschmissen. Aber wenn man das als Bildprobleme sieht, dann sind das einfach Videodatenpakete, nix IGMP. Wo hast Du da was von IGMP gelesen ?

Zitat von te36

Macht das TV-Headend ueberhaupt Multicast ? Das ist doch Unicast.

TV-Headend kann grundsätzlich Multicast empfangen (keine Überraschung). Dafür braucht es je auf CLient-Seite normalerweise keine besondere Programmierung. Eine Ausnahme vielleicht ist SSM - source specific multicast. Auch das kann tvh grundsätzlich. Senden tut tvh nach meinem Verständnis immer puren mpeg-ts als unicast tcp.

SAT-IP Protokoll kann nach meinem Verständnis sowohl Multicast als auch Unicast versenden. Was jetzt aktuell Sat-IP Server nutzen bzw. ob das konfigurierbar ist, kann ich nicht beurteilen.

Aus der Sat-IP Spezifikation: "SAT>IP clients (being at a minimum only UPnP Control Points) do not announce their presence. For this reason, a client leaving the network is not detectable at this level. The SAT>IP protocol however implements RTSP and IGMP which permit to detect the presence or absence of a client (RTSP session timeout, IGMP membership queries)"

Word template (satip.info)

Aber in dem case steht ja auch, das das dann eben zum komplettausfall des Videostreams fuer z.b. 10 Sekunden führt. Bis halt wieder mal IGMP funktioniert und der Datenstrom ankommt. Aber Deine Fehlerbeschreibung ist ja kleinere Aussetzer im Bild. Was eher danach klingt, das da irgendwo bei der paketierung von MPEG nach UDP mal Ethernetpakete produziert werden, die kleiner als 60/64 byte sind und dann vom Megasat nicht korrekt gepaddet werden. Kapiere allerdings im Moment nicht, warum da so kleine Pakete bei rumkommen sollten. Muesste man mal packet-traces sehen.

War das jetzt der tcpdump wo kein verlust ist ?

1328 sind 7 von diesen 188 grossen MPEG-TS blocken plus 12 byte RTP header.

Probier mal "-T rtp" um das RTP auch noch daignostiziert zu kriegen, kann mich leider nicht mehr erinnern, ob/wie man da die timestamps verwenden kann um verlorene pakete angezeigt zu bekommen, muesste ich auch erst mal wieder probieren. Wahrscheinlich einfacher mit wireshark das kann mehr auseinandernehmen als tcpdump.