Artefakte bei rtsp>UDP

[Moses]

Ich glaub nicht, dass der lokale NIC überflutet wird. Der wird die UPD Pakete einfach auf die Leitung hauen. Das sollte der auch noch bei 100Mbit/s hinkriegen und bei 1Gb/s sowieso. Und die Pause im Flow Control ist ja nicht Sekunden lang, sondern nur Bruchteile von Sekunden... und das ist genau das, was man im RS beim senden, zumindest mit UDP, sowieso machen sollte.

[jasch]

Hi wollte nur mal kundtun das ich das selbe "Problem" habe.(läßt sich ja mit tcp umgehen deshalb erstmal halb so wild)

Unicast 100% ok

RTSP udp ca alle 2-3min disc.(Pixelt dann im Bild)

RTSP tcp 100% ok.

 

Mein Netzwerk is komplett GBit, switch ist ein HP Procurve 1810G - 24 GE.

Flowcontrol on oder off macht keinen unterschied.

Ich werde morgen mal die onboard Realteks durch intel nics ersetzen und mal weitertesten.

 

MFG jasch

[Derrick]

..jetzt kann ich auch mit ergebnissen aufwarten

 

Aufbau: 2 rechner mit gemixtem netzwerk (1Gb und 100Mb),beide mit RS 1.26.0.11 und TransEdit 4.0.2.14

 

Rechner 1: Samsung i7 laptop,win7/64; NIC: Realtek PCIe GBE Family Controller 1Gbps; devices: TBS5925, Prof7500

Rechner 2: Dell Intel Pentium M laptop, XP prof SP3; NIC: Broadcom 440x 100Mbps, device: FireDTV-S2

 

Die tests sind qualitativ und grob quantitativ. Es wurde jeweils versucht, die maximale rate ohne paketverluste mit dem analyzer zu ermitteln.

 

a) 2 -> 1: die firedtv hat direkt angeschlossen eine grenze bei ca. 60Mbps. Mit TCP gibt es keinerlei verluste bis zur nativen grenze. UDP drosselt alles über ca. 35Mbps. Es läuft also nur ein dvb-s, 22000, 5/6 astra-transponder ohne verluste.

 

b ) 1 -> 2: TCP geht problemlos bis 65Mbps (und wahrscheinlich mehr); UDP geht nur bis ca. 55Mbps. Über der grenze scheint es zunächst fehlerlos zu laufen aber nach ca. 10s hagelt es missing packets. Dabei ändert sich die angezeigte gesamtrate (57Mbps bei einem 60Mbps transponder) nicht, sodass in den 10s irgendein puffer vollaufen muss.

 

Irgendwelche tweaks bei den NICs habe ich nicht probiert, aber es scheint auch so deutlich: RTSP mit UDP sucks

[MaxB]

@Derrick: Kauf Dir doch mal ordentliche Hardware und nicht solchen "Billig-Kram"

Anbei ein Screenshot mit folgender Hardware:

Test mit Intel GBe (am Server) und Intel 100MBit am Client-PC (Win 8Pro), TransEdit streamt 2 x 64-QAM TS von der ARD gleichzeitig per UDP und nach ungefähr 20 Minuten Laufzeit ergab das den angehängten Screenshot. Beachte bitte auch die Paketverluste im Ressourcenmonitor (0)

 

Edit: @Derrick: Jabe ich ganz vergessen zu schreiben: Im Server (WHS2011) stecken übrigens die "billigen" Tuner von DD und nicht die teuren von TBS , haben die überhaupt so stabil laufende DVB-C Tuner mit so schnellen Umschaltzeiten und gut funktionierender CI-Unterstützung???

Um es auf dem Punkt zu bringen: Generell macht der Recording-Service seine Sache sehr gut und ich habe früher auch viele Probleme damit gehabt, allerdings hatte mir Lars immer wieder am Telefon gesagt, "das muss an Deinen Treibern und an Deiner Hardware liegen..." und seitdem ich vor über 1 Jahr auf ordentliche Hardware umgestellt habe läuft es absolut *TOP* bei mir (und das an beiden Wohnsitzen)!

Edited August 19, 2013 by MaxB

[Derrick]

 

@Derrick: Kauf Dir doch mal ordentliche Hardware und nicht solchen "Billig-Kram"

Der DVBViewer sollte auch ohne professionelle hardware fehlerfrei funktionieren. Woran es liegt, weiss ich auch nicht, aber RTSP/UDP scheint eine unglückliche kombination. Warum kein TCP, wenn es performanter ist? Das netzwerk ist normalerweise klein und es besteht auch keine gefahr, dass pakete einander überholen können. Timing ist bei dvb inhärent durch die PCR sichergestellt. Man könnte höchsten noch untersuchen, ob das streaming ein grösseres jitter zur folge hat (4T2 Content Analyser bietet dafür analysemöglichkeiten). Also wenn hier kein verbugtes UDP vorliegt, würde ich jedem zu TCP raten.

 

@MaxB, angesicht deiner bilder würde ich sagen, selber schwächling

 

Es scheint ein grosser unterschied zu sein, ob man 2 verschiedene muxe streamt oder einen dicken, auch wenn er kleiner als die 2 zusammen sind. Wenn du mal bitte schauen möchtest

 

ps. beide RTSP devices laufen hier natürlich mit UDP

[MaxB]

Der DVBViewer sollte auch ohne professionelle hardware fehlerfrei funktionieren. Woran es liegt, weiss ich auch nicht, aber RTSP/UDP scheint eine unglückliche kombination. Warum kein TCP, wenn es performanter ist? Das netzwerk ist normalerweise klein und es besteht auch keine gefahr, dass pakete einander überholen können. Timing ist bei dvb inhärent durch die PCR sichergestellt. Man könnte höchsten noch untersuchen, ob das streaming ein grösseres jitter zur folge hat (4T2 Content Analyser bietet dafür analysemöglichkeiten). Also wenn hier kein verbugtes UDP vorliegt, würde ich jedem zu TCP raten.

 

Deshalb hatte Lars von Anfang an UDP und TCP zur Auswahl gestellt und es ging in diesem Thread nur um einen TV-Service > 11 MBit (arte HD)! Das was Du hier daraus machen möchtest passt absolut nicht zum Thema!

 

@MaxB, angesicht deiner bilder würde ich sagen, selber schwächling

 

Stimmt einen "so dicken" kann ich nicht zeigen, im Kabel steht aktuell nur 256-QAM mit 50,87 Mbps zur Verfügung und beim Sat-Empfang habe ich auch nur Astra 19,2°. Einen "so dicken" hat allerdings auch nur eine Minderheit hier im Forum...

 

a) 2 -> 1: die firedtv hat direkt angeschlossen eine grenze bei ca. 60Mbps. Mit TCP gibt es keinerlei verluste bis zur nativen grenze. UDP drosselt alles über ca. 35Mbps. Es läuft also nur ein dvb-s, 22000, 5/6 astra-transponder ohne verluste.

 

Es scheint ein grosser unterschied zu sein, ob man 2 verschiedene muxe streamt oder einen dicken, auch wenn er kleiner als die 2 zusammen sind. Wenn du mal bitte schauen möchtest

ps. beide RTSP devices laufen hier natürlich mit UDP

Das glaube ich DIR erst wenn Du den Ressourecenmonitor mit entsprechender Darstellung postest, besonders wenn ich mir das zuvor gepostete nochmal in Erinnerung rufe

So, ich werde jetzt nichts mehr zu Deinen Ausführungen schreiben, da es einfach sinnlos ist, sorry!

[Derrick]

@MaxB du hast dich doch bis vor den letzten 2 posts als weltmeister gefühlt

 

Ich versuche nur zu zeigen, dass RTSP/UDP schlechter und nicht nötig ist. Dafür sind vergleichende grenzwerte genau das richtige. Der ausgangspunkt des topics war natürlich ein anderer, aber es lässt sich imho gut übertragen. Für schwachbrüstige HTPC-hardware ist die kombination RTSP/UDP anscheind gar nicht geeignet. Und ob du mir nun glaubst oder denkst, ich poste hier potemkinsche dörfer, ist mir wurscht.

[dbraner]

Hab jetzt nicht den ganzen Thread gelesen, also entschudligt bitte, wenn die Frage schon gestellt wurde:

 

Welche Paketgröße verwendet der Recservice bei UDP? Ggf. werden die UDP Pakete fragmentiert, was zu den Verlusten führen könnte.

 

Ich kann das übrigens bestätigen, allerdings tritt der Paketverlust bei mir so selten auf, dass es nicht stört. Und wenn doch, kann ich TCP oder Unicast verwenden.

[Griga]

Welche Paketgröße verwendet der Recservice bei UDP?

 

Die Benutzung von Suchfunktionen ist aber auch wirklich unzumutbar schwierig Für manche jedenfalls...

 

http://www.DVBViewer.tv/forum/topic/52888-artefakte-bei-rtspudp/?p=392222

http://www.DVBViewer.tv/forum/topic/52888-artefakte-bei-rtspudp/?p=392236

[dbraner]

 

Da trau ich mich ja fast nicht mehr zu fragen: Verwendet der RS bei RTSP/UDP Raw Sockets?

 

(diesmal hab ich sogar nach "raw sockets" gesucht).

[mague]

 

Da trau ich mich ja fast nicht mehr zu fragen: Verwendet der RS bei RTSP/UDP Raw Sockets?

 

(diesmal hab ich sogar nach "raw sockets" gesucht).

Vermutlich nicht, da raw sockets eigentlich dafuer da sind TCP/UDP zu vermeiden.

[dbraner]

Ich frag nur, weil im Windows Media Server Umfeld gerne UDP mit RAW sockets verwendet wird, um Paketgrößen zu realisieren, die über der eingestellten Größe liegen.

 

Dazu gab es jetzt auch einen Patch von Microsoft.

 

Aber wenn das nicht genutzt wird Haken dran.

[omnium]

Deshalb hatte Lars von Anfang an UDP und TCP zur Auswahl gestellt und es ging in diesem Thread nur um einen TV-Service > 11 MBit (arte HD)! Das was Du hier daraus machen möchtest passt absolut nicht zum Thema!

aha..es geht um 'Artefakte bei rtsp>UDP' und imo ist hier absolut nix Off Topic und die Option 'RTSP>TCP/IP' gibt es bei keinem der kommerziellen SAT>IP Devices/Cients. Die haben anscheinend alle kein Herz für "Billig-Kram"..BTW ist meine HTPC-Hardware sehr performant und inzwischen nur noch mit Intel NICs bestückt und min. mit einem Intel I3 ausgerüstet, der nur vor sich hin idelt.

 

@Derrick

Ich versuche nur zu zeigen, dass RTSP/UDP schlechter und nicht nötig ist..

..erzähle das doch mal den SAT>IP Protagonisten.

 

@all/'Beta Tester'

Wenn Ihr wirklich interessiert seid, das 'Problem' zu ergründen, beherzigt den Tip von Tjod, sorgt für eine gemeinsame Basis und testet euer _LAN_ wie vorgeschlagen zB. mit jperf ohne den Einfluss des RS/chinesischen Freunde/TransEdit/Sat/Kabel/???. Hardware/User/Hersteller Bashing ist nur kontraproduktiv und bringt absolut nix.

Wie gesagt ist bei mir je nach PacketSize _nur_ 30-60 Mbit/sec über UDP möglich und ich weiss leider immer noch nicht ob das 'normal' ist bei einem 100Mbit Lan oder ob das an meinem "Billig-Kram" liegt.

Edited August 20, 2013 by omnium

[Derrick]

Statt eines simulierten tests habe ich doch die raten bei mit transedit ermittelt. Mit dem 100Mbps client kam ich auf ca. 55Mbps transferrate bei UDP mit einem port. Mit 2 devices gleichzeitg sogar auf über 80Mbps.

 

 

@Derrick

Quote

Ich versuche nur zu zeigen, dass RTSP/UDP schlechter und nicht nötig ist..

..erzähle das doch mal den SAT>IP Protagonisten.

 

Das gilt für die vorliegende situation. Vielleicht ist ja auch ein bug drin.

[Derrick]

@all/'Beta Tester'

Wenn Ihr wirklich interessiert seid, das 'Problem' zu ergründen, beherzigt den Tip von Tjod, sorgt für eine gemeinsame Basis und testet euer _LAN_ wie vorgeschlagen zB. mit jperf..

..dir zu liebe und weil ich auf testtools stehe. Ist besser als das tv-programm

 

Der echte betrieb mit dem RS bringt eine höhere rate (s. post weiter oben)

[dbraner]

Interessanter Artikel: Wie TCP Traffic zu UDP Packet Loss führen kann und was man dagegen tun kann (kleine UDP Pakete verwenden):

 

http://www.isoc.org/inet97/proceedings/F3/F3_1.HTM

 

Allerdings sind extrem kleine UDP Pakete auch nicht das gelbe vom Ei, da dann der Protkoll Overhead sehr groß ist was wieder Netto-Bandbreite kostet.

 

Mir scheint, die beste Lösung ist TCP zu verwenden, zumal man immer TCP-Traffic hat und somit den oben beschriebenen Effekt.

Edited August 20, 2013 by dbraner

[Derrick]

..der artikel beschreibt eine andere umgebung (WAN) und trifft auf unser problem nicht zu.

Mir scheint, die beste Lösung ist TCP zu verwenden..

..solange es nicht gelingt, die probleme in den griff zu kriegen. Man sieht ja z.b. mit wireshark sehr schön, dass TCP/IP wegen der flusskontrolle mit Acks eigentlich weniger effektiv ist. Trotzdem ist die leistung im RS höher.

[omnium]

..dir zu liebe und weil ich auf testtools stehe..

danke...spätestens jetzt weiss ich, daß ich einem Phantom hinterhergejagt bin.

[dbraner]

..der artikel beschreibt eine andere umgebung (WAN) und trifft auf unser problem nicht zu..

 

Verstehe Deinen Einwand nicht. Im WAN kommt auch kein anderes IP zum Einsatz. Der TCP-Traffic ist zwar deutlich höher, die beschriebenen Effekte dürften aber auch in Netzen mit geringer Anzahl TCP-Verbindungen auftreten.

 

Du sprichst Wireshark an: Wenn Du lokal (auf Client oder Server) mit Wireshark misst, siehst Du nur den Traffic der direkt verbundenen PCs. Wenn Du alles erfassen willst (und damit alle möglichen Störungen) musst Du alles an einen HUB anschließen. Dann hast Du wiederum das Problem, dass der HUB selbst suboptimal für Bandbreiten intensive Verbindungen ist, weil er alle Ethernet Frames auf alle Ports verteilt, also die Messung das Ergebnis beeinflusst. Für eine objektive Messung brauchts einen Switch mit Mirror-Port. Und wer kann sich den schon leisten.

 

Schwierig das ganze ...

Edited August 21, 2013 by dbraner

[Derrick]

Im WAN können datagramme einander überholen. Das ist im kleinen LAN nicht der fall.

 

Ich habe nur die performance am NIC gemessen und die ist mehr als ausreichend. In meinem LAN geht es über 2 switsches (100Mb und 1Gb). Die UDP-transferrate ist vom Gb-NIC zum 100Mb-NIC fast doppelt so hoch wie in der gegenrichtung aber immer noch hoch genug zum gucken von HD. Allerdings reicht es für den analyzer mit UDP nicht mehr. (TCP ist hier mit ca. 55Mb gegenüber UDP mit 35Mb wesentlich höher).

 

Bei @omnium muss es doch server selbst liegen, denn selbst mit cross cable war das ergebnis schlecht.

[omnium]

Bei @omnium muss es doch server selbst liegen..

nein...das Phantom ist tot!

[Derrick]

..wieso? Oder hast du dich ganz vom DVBViewer verabschiedet?

[omnium]

..wieso? Oder hast du dich ganz vom DVBViewer verabschiedet?

nein!

[Derrick]

..erst entfachst du einen RTSP/UDP sturm und jetzt schweigst du.

[omnium]

meine Theorien zu dem 'Problem' sind zu spekulativ und meine Schlussfolgerungen aus den Erkenntnissen würden hier nur böses Blut geben...deshalb behalte ich die besser für mich, aber abgehakt habe ich die Suche nach den Gründen noch immer nicht...

.

Habe eben mal die _kostenlose_ SAT>IP.info DVBViewer Lite Version mit dem RS getestet. Mir fällt besonders auf, daß der DVB Source Filter anscheinend nicht benutzt wird 'Filter State: Stopped'..



..verstehe ich gar nicht...eine weiterer VLC UPnP/RTSP Client über den RS ist auch nicht möglich..???

Ich 'befürchte' allerdings mit der Lite Version gibt es nicht die hier diskutierten RTSP-UDP-Probleme..werde ich aber noch testen....mit der 0815 'Billig Hardware' also dem jetzt brachliegenden Realtek NIC...da müsste ja bei >12-13 Mbit/sec wieder hängen im Schacht sein.

Edited August 22, 2013 by omnium

[nuts]

Glaube schon das der DVBViewer Sourcefilter verwendet wird (mangels Alternativen).

Genaueres kann die Graphedit / Graphstudio zeigen.

Bild ist schon etwas komisch, aber mit dem OEM Versionen kenne ich mich auch nicht besonders aus.

 

 

Dann macht mal den RTSP-UDP Test mit der Lite-Version.

Würde da aber keine Änderung erwarten, da bei dir ja unterschiedliche Client-Software (DVBV Pro & VLC, XBMC) den gleichen Fehler produziert hat.

Edited August 22, 2013 by nuts

[omnium]

ok..

 

 

..dann ist das wohl nur eine falsche Anzeige...da steht immer 'stopped'.

 

Würde da aber keine Änderung erwarten, da bei dir ja unterschiedliche Client-Software (DVBV Pro & VLC, XBMC) den gleichen Fehler produziert hat..

wir werden es sehen...morgen ...mein Bauch sagt mir, daß es keine Artefakte geben wird...

.

Mein Bauchgefühl war trügerisch...alles wie gehabt, also auch Artefakte bei Datenraten >12-13 Mbit/sec mit dem Realtek NIC...>20 MBit/sec sollten/müssten es wenigstens sein wie mit dem Intel NIC. Wegen der Messungen mit jperf und den Ergebnissen mit dem Netstream Plugin, fällt es mir immer noch sehr schwer, den Realtek onboard NIC als defekt/billig/??? abzuhaken...das 'Problem' kommt zu den X-Akten.

Edited August 23, 2013 by omnium

[dbraner]

Also man nehme:

• Server mit Windows 8 64 Bit und aktuellem Recservice
• Geswitchtes GBit Ethernet
• Client PC mit Windows 7 DVBViewer aktuelle Version
• RTP Device mit UDP
• Beliebiger SD Kanal

Dann startet man einen Browser und ruft eine relative überladene Seite auf (z.B. bild.de). Bei mir treten sofort Discontinues im DVBSource Filter verbunden mit Rucklern auf. Sobald die Webseite geladen ist, ist wieder alles gut.

 

Jetzt umkonfiguriert auf RTP über TCP. Selber Test, keine Discontinues.

 

Nun wie hier http://www.youtube.com/watch?v=0Wj-MktpYD0 beschrieben auf dem Server einen UDP Multicast Stream eingerichtet und auf dem Client ebenfalls mit VLC abgerufen. Dazu wieder mit Browser Webseite geladen und wie blöd Reload gedrückt. Keine Ruckler im Video.

 

Fazit: Irgendwas läuft bei der Übertragung von RTP über UDP beim Recordingservice (oder DVBViewer?) schief.

[Donald24]

UDP ist gegenüber TCP ein verbindungsloses Protokoll. D.h. es gibt keine Sicherungsschicht, die eine fehlerfreie Übertragung garantiert. Guckt mal in der Wiki: es war gemacht, für Echtzeit-Anwendung, die keinen Anspruch auf Vollständigkeit haben!

 

Die UDP-Performance hängt ab, von:

 

1. Hardwareimplementierung

2. Treiber

3. Kabel (stark vernachlässigbar bei hausüblichen Längen)

4. Switch (Level 3 macht hier den Unterschied)

5. Laune

 

Eingangs wurde doch sogar ein Bug in der Software vermutet. So ein Quatsch! Versucht mal das OSI-Modell zu verstehen. In der Anwendungsschicht 7 (DVBclient) kommt nur das an, was die unteren Schichten ermöglichen, und UDP ist nun mal als Paketdienst zu verstehen "ohne Garantie". Interessant ist hierbei, wie gross die Differenzen sind, bei unterschiedlichen Netzwerkkarten. Aber ein guter Level-3-Switch sollte alle Probleme diesbezüglich auch mit den vermeintlichen bösen Realtek-Karten beseitigen. Aber auch hier gilt: Es gibt keine Garantie für den Durchsatz! Es ist und bleibt UDP. Ich glaub, der Ursprung für die Entscheidung für das Protokoll SAT>IP UDP zu verwenden waren mittelgroße Netzwerke, die mit professionellen Switch-Equipment auf Multicasting-Ebene das Signal verteilen können. Was ich bei mir zuhause davon merke (gegenüber TCP) sind ein paar ms bessere Umschaltzeiten. Das ist alles. Und wenn ihr nicht mehr als fünf clients gleichzeitig versorgt -> stellt um auf TCP!

 

Jetzt kann man natürlich Hardware-Benchmarks machen ohne Ende, aber letztlich ist das doch dann eher was für den Thread "Pimp my UDP-throughput".

[omnium]

Eingangs wurde doch sogar ein Bug in der Software vermutet. So ein Quatsch! Versucht mal das OSI-Modell zu verstehen...

aha..Du bist ein echter Spezi und kannst mir sicher auch erklären warum das..http://www.DVBViewer.tv/forum/topic/52888-artefakte-bei-rtspudp/?p=392157 fehlerlos funktioniert hat mit dem defekten/billig Realtek NIC und 0815 Switch. BTW habe ich uA. auch mal mit einen Layer 3 Switch/Direktverbindung getestet..._kein_ Unterschied!

Edited August 23, 2013 by omnium

[trudeh]

Telestar OEM vs DVBViewer Pro

 

Ich kämpfe auch mit RTP und UDP.

Benutze seit vielen Jahren ohne Probleme die klassische Variante RS mit mehreren DVBViewer Clienten.

 

Jetzt hab ich mal einen Telestar Digibit R1 eingebunden.

Der macht weder über den RS noch direkt mit den DVBViewer Pro Clienten Spass.

Meistens bleibt nach einiger Betriebszeit (oft nur wenige Minuten) das Bild stehen, der Ton läuft noch ein wenig nach, und dann geht nichts mehr.

Der DVBViewer muss dann per Task Manager geschlossen werden.

Spätestens wenn ein zweiter Client gestartet wird steigt der erste Client aus.

 

Ich hab jetzt mal testweise die Telestar OEM Software installiert, die WESENTLICH stabiler als der DVBViewer Pro läuft.

Sie hakelt vielleicht auch mal kurz, was aber auch an meiner WLAN Verbindung liegen kann, läuft dann aber weiter.

Auch das Starten eines weiteren Clienten lässt die OEM Software unbeeindruckt.

Sicherlich hab ich ein verkorkstes Netzwerk mit mehreren Routern und Switches.

Trotzdem scheint es ja ein Implementierungsfehler im DVBViewer Pro zu sein, da die OEM Version deutlich besser läuft!

[Donald24]

omnium: mein bereitschaft für nachhilfe ist hiermit erschöpft!

 

Trudeh: wie machst du das? Bindest du den Digitbit R1 als Recordingsserver-device ein? Ich habe auch die R1-Box, allerdings betreibe ich die als direktes Client-Device über RTSP/UDP, und hab im Recordingsservice meine CineS2 nur für Aufnahmen und EPG-Aufbereitung. Ich habe mit der R1-Box null Probleme an testweise drei DVBViewer-clients + Ipad. 2x LAN, 2x WLAN.

[omnium]

omnium: mein bereitschaft für nachhilfe ist hiermit erschöpft!

schade, hatte mich schon auf eine Erklärbär-Antwort gefreut.

allerdings betreibe ich die als direktes Client-Device über RTSP/UDP..

dann betreibe die doch mal über den _RS_...vielleicht geht Dir dann ein Licht auf/ist der 'Quatsch' dann kein Quatsch mehr.

 

--

Und er kommt zu dem Ergebnis: Nur ein Traum war das Erlebnis.

Weil, so schließt er messerscharf, nicht sein kann, was nicht sein darf.

[Christian Morgenstern, Die unmögliche Tatsache]

Edited August 24, 2013 by omnium

[dbraner]

Welchen Layer 3 Switch verwendest Du? Sind ja doch etwas teurer als die normalen. Nur mal Interesse halber, falls ich auch mal einen haben möchte.

[omnium]

..meinst Du mich? Zyxxel Dimension ES-2008..den gibt es aber schon länger nicht mehr.

Ein 'Layer 3 Switch' ist imo mehr Marketing und nicht notwendig in einem Heimnetzwerk...wenn das mit SAT>IP/RTSP>UDP nicht hinhaut in einem 0815 Heim-Netzwerk, taugt der Standard oder der RS nix...der Standard ist imo ok.._nur_ der RS hat seine Probleme.

Edited August 24, 2013 by omnium

[noxx]

Habe ja das selbe Problem, aber Switch ist nicht das Problem.

 

DVBViewer/RS + Xmbc = Artefakte

Mediaportal TV Server + Mediaportal Client = Keine Artefakte

 

 

posted with

 

Edited August 25, 2013 by noxx

[Griga]

@noxx: Ich hatte dich bereits per PM darauf aufmerksam gemacht. Verhindere bitte das "Please tell me how to disable the Tapatalk signature on my device." in deinen Beiträgen. Ansonsten muss ich deine Beiträge verhindern. Letzte Aufforderung...

[dbraner]

..meinst Du mich? Zyxxel Dimension ES-2008..den gibt es aber schon länger nicht mehr.

Ein 'Layer 3 Switch' ist imo mehr Marketing und nicht notwendig in einem Heimnetzwerk...wenn das mit SAT>IP/RTSP>UDP nicht hinhaut in einem 0815 Heim-Netzwerk, taugt der Standard oder der RS nix...der Standard ist imo ok.._nur_ der RS hat seine Probleme.

Ja Du warst gemeint. Danke für die Antwort. Und ich gebe Dir Recht:stabiles UDP sollte im Heimnetz mit wenig konkurrierendem TCP kein Problem sein.

Vielleicht passiert ja was in einer neueren RS Version. Allerdings weiss ich nicht, welcher der Entwickler sich dem Thema Recording Service angenommen hat. War Lars' Thema ...

[Derrick]

UDP macht eigentlich nur bei multicast probleme. Wenn ich den network plugin mit multicast laufen lasse, funktioniert das im prinzip aber ich komme dann nicht mehr ins internet

[omnium]

UDP macht eigentlich nur bei multicast probleme..

aha..http://www.DVBViewer.tv/forum/topic/52888-artefakte-bei-rtspudp/?p=392157