Jump to content

Störungen im Live-TV bei LAN-Aktivität (Mediaserver)


Klassikfan

Recommended Posts

Hallo! 

 

Ich stelle mal hier ein Problem zur Diskussion, das ich in meiner Konfiguration habe, und das ich gern zufriedenstellend lösen würde. 

 

Folgende Konfiguration: 

 

Windows-PC mit DVB-Mediaserver, in dem zwei TV-Karten stecken (Digital Devices, 1x Sat, 1x Kabel/DVB-T)

Dieser "Server"-PC dient mir als "Videorekorder" und Server für dahinter hängende PCs (Notebook etc), auf denen DVBViewer als Client hängt. 

 

Aufnahmen erfolgen lokal auf dem Server-PC, Videoschnitt/bearbeitung auf dem Client-PC. 

 

Mein Problem ist, daß ich recht viel über diese Verbindung fernsehe, und das livebild immer ins Stocken gerät, wenn auf dem LAN Aktivität ist. Am Schlimmsten ist es, wenn ich gleichzeitig mit dem Fernsehen auf Aufnahmen des Servers zugreife, um sie zu schneiden. Aussetzer, Klötzchen etc. sind die Folge. 

 

An der Bandbreite liegt es nicht. Beide PCs haben 2,5GBit-LAN, und das Live-TV benötigt nur so 16-18MBit/s

 

Ich hab aus lauter Verzweiflung schon ein separates Netz aufgemacht. Also zusätzlich über USB-Adapter eine LAN-Verbindung etabliert über die der TV-Stream laufen kann. Ist aber unter Windows eine echte Hängepartie, da hier verschiedene Netze mit unterschiedliche IP-Räumen nötig sind, mit denen das System nur schlecht klarkommt. Daß zudem DVBViewer ein "privates Netzwerk" verlangt, macht es auch nicht leichter. Den zumindest mit Bordmitteln ist es sehr schwer, einem Netzwerk, das gar nicht als solches erkannt wird, den Status "privat" zuzuweisen. 

 

Ich würde das gern etwas vereinfachen, denn Bandbreite ist, wie gesagt, eigentlich genügend vorhanden. 

Was könnte ich tun? Könnte man den Live-Stream irgendwie im Netzwerk "tunneln", und so sicher vor Einflüssen anderer Netzwerk-Aktivitäten machen? 

Link to comment

Wenn es um eine Verbindung zwischen Media Server und DVBViewer geht, probiere im DVBViewer unter Hardware -> verwendetes RTSP Network Device selektieren -> Einstellungen -> Protokoll von UDP auf TCP umzustellen. Danach OK im Einstellungen-Dialog und Übernehmen im Optionen-Fenster.

 

TCP beinhaltet im Gegensatz zu UDP eine Fehlerkorrektur. Verlorene Datenpakete werden erneut beim Server angefordert. Dafür ist der Protokoll-Overhead größer, d.h. es braucht etwas mehr Datenrate.

 

Link to comment

Was Du da beobachtest, ist "normales LAN Verhalten".

 

TCP/IP verteilt seine Bandbreite gemäss dem Grundsatz "take it all". Die vorhandenen Verbindungen erhalten erstmal alles, egal, ob sie es brauchen, oder nicht.

Kommt eine neue Verbindung hinzu (z.B. Dein Filetransfer), werden erstmal ALLE laufenden Verbindungen angehalten, und die Bandbreite umsortiert.

Das sind dann die Momente Deiner "Klötzchen".

Das ist ein fundamentales und nicht lösbares Problem, wird leider von den Streamingfreaks meistens verdrängt, sie argumentieren und denken nach dem "Highlander-Prinzip" ("es kann nur einen geben" und "nach mir die Sintflut")

 

Im Laufe der Jahre wurde versucht, diesem inzwischen unangenehmen Feature (ursprünglich war das eigentlich "gut", da es für eine gerechte Verteilung sorgt) entgegenzutreten, die angepriesene Lösung heißt "Qos" (Quality of Service).

Leider wurde das nur halbherzig implementiert, erfordert einen Riesen Verwaltungsaufwand und scheitert schon, sobald ein Gerät im LAN da nicht mitspielt (oder nicht entsprechend konfigurierbar ist).

Kann man also versuchen, hilft aber meistens auch nicht.

 

Das Einzige, was wirklich funktioniert, sind physikalisch getrennte Netze (nein, auch keine VLANs, wie manche gebetmühlenartig runterbeten, auch die werden zwangsläufig bedämpft, da sich am Ende alles über ein einziges Kabel zwängen muss). Also sowohl den Media Server, als auch die "guck-pcs" mit extra LAN Karte ausstatten und diese jeweils mit einem eigenen Switch verwenden. Beim Mediaserver konfigurierst Du dann ,dass Streaming nur über diese Karte möglich ist.

 

Der hier vorgeschlagene Umstieg auf TCP zwecks "Fehlerkorrektur" ist in sofern Unsinn, weil zwar die verlorengegangenen Pakete nachgeholt werden, aber statt Klötzchen hast Du dann Hakler und MickyMouse Effekte.

Ist also mehr "den Teufel mit dem Bezelbub" austreiben.

 

 

Link to comment

Solange er genug Bandbreite übrig hat sollte kein Ruckler auftreten mit TCP.

Hatte exakt das selbe, da sich bei mir das LAN über mehrere Switche verteilt und ein Raum sogar mit Powerline angebunden ist.

Irgendwo gibt es da ein Problem mit den UDP Paketen.

Nach Umschalten auf TCP seit Jahren kein Problem mehr.

Auch bei hohen Datentransfers hatte ich noch keine Ruckler mit TCP.

Link to comment

Habs jetzt ne Weile ausprobiert, und es scheint zu funktionieren. Sichtbare Aussetzer der Ruckler gibt es keine mehr. 

Hab auch mal einen "Extremtest" gemacht, und auf dem Server eine große Datei auf die SSD kopiert und dann auf den Client-PC (ebenfalls SSD) kopiert, während gleichzeitig Live-TV übertragen wurde. Laut Taskmanager liefen 2,1 GBit/s übers LAN, das somit nahezu voll ausgelastet war. Dennoch keine Ruckler oder Aussetzer. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...