Nach wechsel des USB-Ports kein DVB-C-Empfang mit dem Viewer über den Server

[Bob.Dig]

"Sender nicht verfügbar vom Server". 

Zuerst hatte ich ein Problem mit unterschiedlichen Subnets in Verdacht, habe aber eine Direktverbindung zwischen den beiden, sodass dies ausscheidet. Die Firewall war auf beiden Systemen deaktiviert. Anbei die Logs.

Da der lokale Viewer direkten Zugriff auf die DVB-Hardware hat und funktioniert, ist es kein Hardware-Problem.  

 

Desktop.zip

Edited August 28 by Bob.Dig

[Griga]

Im DVBViewer kommt es zu einem Timeout-Fehler im Zusammenhang mit dem neuen TCP Interleaved Modus. Du hast die RTSP Netzwerkgeräte im DVBViewer auf TCP (statt UDP) konfiguriert, deshalb kommt der neue Modus jetzt zur Geltung.

 

Das Timeout beträgt beim Tunen satte 15 Sekunden, aber dein Media Server braucht offenbar noch länger, um den Hauppauge WinTV dualHD zu Initialisieren und zu tunen, wie das svcdebug.log vermuten lässt. Um 12:49:58 kommt die Tune Request vom DVBViewer, um 12:50.09 ist die Hardware initialisiert (11 Sekunden), um 12:50:17 das Tunen abgeschlossen (8 Sekunden). Macht zusammen 19 Sekunden. War der Stick schon immer so lahm?

 

Klappt es, wenn du den DVBViewer auf UDP umstellst?

 

[Bob.Dig]

vor 17 Minuten schrieb Griga:

wenn du den DVBViewer auf UDP umstellst?

Klappt auch nicht.

Wenn ich die Limits im remote Viewer hochstelle, funktioniert es trotzdem nicht. Mein Eindruck ist aber, dass diese eh nicht berücksichtigt werden, die Fehlermeldung kommt "zu schnell". 

Hier noch das Log des lokalen Viewers (per RDP-Session), den ich aber quasi nie nutze. 

 

Insgesamt würde ich sagen, das Initiieren dauert bei mir immer schon recht lange. 

Edit: Was immer noch geht ist meine Internet-Streaming-Lösung über den Server, also es scheint sich auf ein DVB-Problem zu beschränken. 

DVBViewer.log

Edited August 18 by Bob.Dig

[Bob.Dig]

@GrigaHabe den Stick in einen anderen Port gesteckt, nun geht es wieder. 🙃

[Griga]

Schauen wir mal, wie lange und ob für immer. Für mich ist das schon ein Hinweis auf ein Problem, das bei langen Tuning-Zeiten entstehen kann, und um das ich mich kümmern muss. Ich konnte es vorhin auch mal mit einer Kette Media Server 1 -> Media Server 2 -> DVBViewer Client nachvollziehen (alles Sat>IP mit TCP Interleaved), aber nur manchmal.

 

Im Moment bin ich leider etwas behindert, da ich aufgrund einer Zimmer-Renovierung einen großenTeil meines Heimnetzes (4 PCs und OctopusNet Server) abbauen musste. Jetzt habe ich hier neben dem Arbeits-PC nur noch einen Laptop und Android/iOS-Mobilgeräte.

 

[Bob.Dig]

vor 24 Minuten schrieb Griga:

aufgrund einer Zimmer-Renovierung

Dann gutes Gelingen dabei. Die neue Lupenfunktion ist echt nice.

 

Hier noch ein Log, wo alles wieder geht. Warum der Server betroffen war, aber nicht der lokale Viewer, erschließt sich mir nicht. Der TV-Stick steckte aber in so einem Adapter, den ich jetzt umgangen habe und es läuft alles wie zuvor. 

 

 

svcdebug.log

Edited August 18 by Bob.Dig

[Griga]

Am 18.8.2025 um 19:13 schrieb Griga:

Ich konnte es vorhin auch mal (...) nachvollziehen (alles Sat>IP mit TCP Interleaved), aber nur manchmal.

 

Das Problem in meinem aktuellen provisorischen Setup (wegen der Renovierung) ist folgendes: Der Media Server auf dem Arbeits-PC sendet den TV Stream via WLAN zum Router, und der dann wiederum via WLAN zum Laptop. Das macht bei einem ARD HD-Sender von Astra 19,2° Ost einen Traffic bis zu 25 MBit aus. Und wenn dann noch der DVBViewer-Client auf dem Laptop nach seinem Start 50 MB EPG-Daten vom Server holen will, kommt das WLAN an seine Grenze, und der TV Stream muss leiden, trotz TCP. Dann geht dieses oder jenes schief, d.h. es gibt Bildstörungen, oder ein Timeout schlägt zu.

 

Hier wäre eigentlich QoS fällig, also eine Priorisierung des TV Streams gegenüber den EPG-Daten. Das müsste dann aber die ganze Übertragungskette unterstützen, einschließlich Router. Alternativ könnte ich versuchen, die Datenrate der EPG-Übertragung z.B. auf 1 MBit/s zu limitieren, womit Störungen weniger wahrscheinlich werden. Allerdings würde diese Begrenzung auch wirken, wenn es gar nicht nötig ist, und die EPG-Übertragung beträchtlich verzögern. Tja... was tun?

 

[Bob.Dig]

Ich muss zugeben, dass ich das "lokale" EPG überhaupt nicht nutze, sondern ausschließlich den Webserver. Wenn das vielen so geht, könnte man ggf. tatsächlich die Rate drosseln... 

[Griga]

In Zukunft wird es wahrscheinlich folgenden clientseitigen Tweak im DVBViewer geben:

 

Zitat

EPG-Downloadrate vom Media Server (kbps): Bestimmt die maximale EPG-Downloadrate vom Media Server in kbps. 0 bedeutet unbegrenzt. Bei unzureichender Netzwerk-Bandbreite kann der Download einer großen Menge EPG-Daten nach dem DVBViewer-Start einen gleichzeitig vom Server empfangenen TV Stream beträchtlich stören. Eine Begrenzung der Datenrate (z.B. auf 1000 kbps = 1 MBit/s) verringert Wiedergabeprobleme, verlängert aber die Downloaddauer entsprechend.

 

Bei 1000 kbps und 50 MB EPG-Daten zieht sich das Laden dann schon 7 Minuten hin. Hier gilt: So wenig wie nötig, so viel wie möglich, ohne dass es zu Störungen kommt. Das muss man ausprobieren, indem man den DVBViewer mit einem Sender mit hoher Datenrate startet, wie z.B. Das Erste HD via Satellit.

 

Bei einem DVBViewer auf dem selben PC wie der Media Server wird man das nie brauchen, wohl auch nicht bei Gigabit LAN, aber bei einer etwas schwachen WLAN-Verbindung zwischen Server und einem DVBViewer-Client auf einem Laptop wie zur Zeit hier womöglich schon. Bei einer EPG-Downloadrate von mehr als 3000 kbps und TCP Interleaved als Sat>IP-Datentransportmodus wird es bei mir kritisch, und der DVBViewer hängt sich mitunter nach dem Start sogar zeitweise auf.

 

[Bob.Dig]

Heute habe ich das Problem wieder, lokal geht es, über den Server nicht. irgendwo scheint der Wurm drin. 

[Griga]

Leider sind die Logs weg, anhand derer ich der Sache noch mal nachgehen könnte.

 

Ruft dein Remote DVBViewer Client den EPG vom Server ab? Falls ja, schalte das unter Optionen -> DVBViewer Media Server mal probeweise ab. Tritt das Problem nur beim Start des DVBViewers auf, oder auch später bei Anwahl eines anderen Senders oder "Wiedergabe neu aufbauen"?

 

Inzwischen habe ich anhand meiner provisorischen Konfiguration festgestellt, dass es erhebliche Auswirkungen haben kann, wenn der EPG-Abruf vom Server (in einem separaten Thread) und die Initialisierungsphase für den angeforderten TV Stream sowohl server- als auch clientseitig gleichzeitig stattfinden, weil dies eine erhebliche Netzwerk-Last erzeugt. Es können TCP Client-Requests verloren gehen, der Client kann aufgrund von Datenverlusten im Interleaved-Modus den Sync mit dem Server verlieren - da Server-Antworten auf die Requests und TV-Daten über die selbe Verbindung laufen, muss der Client jederzeit wissen, in welcher Art von Datenblock er sich gerade befindet. Fehlen Daten, weiß er das nicht mehr, und die Kommunikation ist aus dem Takt. Deshalb habe ich in der Hinsicht weitere Maßnahmen ergriffen:

• Der EPG-Abruf nach dem DVBViewer-Start wird um 5 Sekunden verzögert, damit er sich nicht mehr mit den anfänglichen RTSP-Kommandos an den Server überschneidet.
• Zusätzlicher Code versucht, den Sync wieder herzustellen, wenn er verloren gegangen ist.
• Von 15 auf 20 Sekunden verlängertes Tune-Timeout (was allerdings zur Folge hat, dass der DVBViewer 20 statt 15 Sekunden festhängt, wenn der Server warum auch immer gar nicht antwortet).

Ich könnte dir eine Testversion zur Verfügung stellen.

 

[Bob.Dig]

@GrigaIch hab den EPG-Empfang deaktiviert und den Viewer neugestartet, Problem besteht weiterhin. Es werden wieder UDP-Verbindungen genutzt. Möglicherweise begannen die Probleme schon vor dem Update, bin mir nicht sicher.

Ich habe aber auch schon einige Vorabversionen hinter mir. Solange ich der einzige mit einem Problem bin, ist es vielleicht ein Einzelfall. 

Eine Testversion nehme ich natürlich gerne. 

Edited August 26 by Bob.Dig

[Bob.Dig]

@GrigaDieser Punkt wäre vielleicht auch noch mal von Interesse, obwohl ich das Timeout auf 30.000 ms geändert habe, kommt die Meldung des Servers, dass der Sender vom Server nicht verfügbar sei, schon deutlich früher. 

 

[Griga]

Das konfigurierbare Connection Timeout ist in der Regel für Tuning zu niedrig. Deshalb wird dafür (bislang) ein hardgecodeter Wert von 15 Sekunden verwendet.

 

[Bob.Dig]

Aufnahmen über den Server sind nicht betroffen, ich kann z.B. die ARD aufnehmen, nur im Remote Viewer gucken geht nicht. 

[Griga]

Du hast eine PM.

[Bob.Dig]

vor 3 Minuten schrieb Griga:

Du hast eine PM.

Holy Moly, es funktionierte sofort. Ja, es hat etwas gedauert, bis der Sender angezeigt wird, aber das war/ist ja zu erwarten gewesen.

[Bob.Dig]

vor 29 Minuten schrieb Griga:

Du hast eine PM.

Damn. Ein paar Minuten später getestet und es geht wieder nicht. Absolut merkwürdig. 

[Bob.Dig]

vor 38 Minuten schrieb Bob.Dig:

Holy Moly, es funktionierte sofort.

Der Grund, dass es sofort ging, war vermutlich der, dass zufällig gerade eine (DVB) Aufnahme lief. 

[Griga]

vor 19 Stunden schrieb Bob.Dig:

Aufnahmen über den Server sind nicht betroffen

 

Es ist nichts betroffen, das direkt auf die Tuner zugreift. Tuning Timeout gibt es nur bei RTSP Netzwerkgeräten.

 

Um die Sache beurteilen zu können, bräuchte ich neue Logs vom Server und vom Remote Client im Debug-Modus.

 

Noch unbeantwortet:

Zitat

Tritt das Problem nur beim Start des DVBViewers auf, oder auch später bei Anwahl eines anderen Senders oder "Wiedergabe neu aufbauen"?

 

[Bob.Dig]

Am 26.8.2025 um 08:00 schrieb Griga:

Tritt das Problem nur beim Start des DVBViewers auf, oder auch später bei Anwahl eines anderen Senders oder "Wiedergabe neu aufbauen"?

Das stellt sich aktuell uneinheitlich dar, Umschalten brachte keine Besserung, der Neuaufbau dann aber schon. 

Jetzt mit Logging stellte es sich so dar, dass Umschalten bereits funktionierte, daher kein Neuaufbau mehr versucht. Vielleicht eine Timing-Frage.

 

20250827_1.zip

Edited August 27 by Bob.Dig

[Griga]

Das war jetzt wohl UDP. Der DMS antwortet beim Tunen wie gehabt nach 17 Sekunden, beim Client gibt es aber nach den nun vorgesehenen 20 Sekunden Tuning-Timeout, die eigentlich hätten reichen müssen, den Timeout-Fehler von Windows höchstpersönlich (Fehlercode 10060). Da scheint es auch netzwerktechnisch zu haken.

 

Die Logs sind leider etwas schlecht vergleichbar, weil es ein paar Sekunden Abweichungen bei der Systemzeit gibt, was für das Problem aber keine Rolle spielen dürfte.

 

Wie sieht es nun mit TCP aus?

 

Interessant wäre zum Vergleich auch mal ein Versuch mit dem DVBViewer 7.3.1.0.

 

vor 9 Stunden schrieb Bob.Dig:

Umschalten brachte keine Besserung, der Neuaufbau dann aber schon. 

 

Nach dem Neuaufbau verwendet der DMS einen zweiten Tuner (Hauppauge WinTV-dualHD DVBC Tuner) , da der erste noch in Verwendung ist (Hauppauge WinTV-dualHD DVBC Tuner 2). Der DMS bekommt ja das Scheitern des Clients gar nicht mit. Aus seiner Sicht ist alles ok., und er liefert nun zwei Streams. Beim zweiten geht es serverseitig einige Sekunden schneller. 

 

Habe gerade keine Zeit mehr, später eventuell mehr...

 

[Bob.Dig]

vor 18 Minuten schrieb Griga:

Wie sieht es nun mit TCP aus?

Hier nun mit tcp. "Empfang" gab es damit nicht. Die haupauge-Site funktioniert gerade nicht für mich, ob es da schon wieder neue Treiber gibt.

Alte Version nur als Client kann ich vielleicht morgen testen. 

 

 

20250827_2.zip

[Griga]

Laut DVBViewer.log: 

19:31:56: Tune Request an Server

19:32:16: Tuning Timeout wie vorgesehen nach 20 Sekunden 

19:32:19: Antwort vom Server, also nach 23 Sekunden

(bei TCP Interleaved kann ich verspätete Antworten im Log sehen, bei UDP nicht).

 

Laut svcdebug.log: 

19:31:56: TCP Verbindung zum Client hergestellt (ergänzt)

19:32:01: Tune Request vom Client. 

19:32:12:  Gerät initialisiert

19:32:19: Gerät getuned, Antwort an Client, also nach 18 Sekunden

 

Ich frage mich gerade , ob die Systemzeiten von Client und Server wirklich um 5 Sekunden auseinanderliegen. Der Zeitpunkt der Serverantwort stimmt nämlich überein. Das würde heißen, es hat allein 5 Sekunden gedauert, bis die Tune Request beim Server angekommen ist.

 

Du hast nicht zufällig Bitdefender oder ähnlichen Sicherheitssoftware-Mist installiert?

 

Edited August 28 by Griga
Ergänzung

[Bob.Dig]

vor 4 Minuten schrieb Griga:

Du hast nicht zufällig Bitdefender oder ähnlichen Sicherheitssoftware-Mist installiert?

Nope. Habe aber die Zeit auf beiden Systemen in den Windows-Einstellungen "synchronisiert" vor dem letzten Versuch.

Edited August 27 by Bob.Dig

[Bob.Dig]

Am 26.8.2025 um 10:11 schrieb Bob.Dig:

Möglicherweise begannen die Probleme schon vor dem Update, bin mir nicht sicher.

Hab nun 7.3.1.0 frisch installiert und auch damit besteht das Problem. Ich vermute, es liegt auch nicht am Server, sondern irgendwas am Rechner, wo das drauf läuft. Werde mal Sachen umstecken und Treiber erneut installieren, sofern möglich. 

[Griga]

vor 28 Minuten schrieb Bob.Dig:

Hab nun 7.3.1.0 frisch installiert

 

Das bedeutet: Bei RTP kommt die alte Methode zum Zug (nicht interleaved, sondern separate Verbindungen für Kommandos und TV Stream, das unterstützt der DMS nach wie vor, wenn der Client es anfordert). Bei UDP hat sich weder server- noch clientseitig etwas gegenüber früher geändert.

 

Dass es in einem Heimnetz 5 Sekunden dauert, bis der Server die TCP Request vom Client erhält, verstehe ich nicht. Als ob jemand das überwacht und den Content erst mal in die Cloud zur Überprüfung schickt, bevor er es zulässt

 

[Bob.Dig]

Habe nun den Stick in seinen "alten Port" gesteckt, damit bestehen die Probleme nicht mehr. Ob das am Haupauge-Treiber liegt oder am Mainboard, ich weiß es nicht. Fakt ist, dass der "alte Port" direkt an die CPU angebunden ist und nicht über den Chipset geht. Da AMD für Windows-Server auch keine Consumer-Komponenten-Treiber mittels Installers bereitstellt, kann das Problem auch irgendwo darin liegen. Auch ist das Board eher speziell. 

 

Habe nun wieder die aktuelle Version vom Viewer frisch installiert und mitgeloggt, auch wenn es ja wieder funktioniert. 

Mir ist das Ganze wohl zu spät aufgefallen, da ich kaum mehr live-TV gucke, sondern eher die Aufnahmen daraus. 

20250828_1.zip

Edited August 28 by Bob.Dig

[Bob.Dig]

vor 51 Minuten schrieb Griga:

Dass es in einem Heimnetz 5 Sekunden dauert

Wäre jetzt die Frage, ob Du das dennoch angehen willst, da es ja lokal funktioniert, oder nicht.

Möglicherweise Energiesparfunktionen, wüsste sonst nicht, woran das liegen könnte. Werde auch noch mal in ein paar Minuten Gegentesten, nicht, dass es noch immer Probleme gibt...

Nach ein paar weiteren Tests würde ich sagen, das Umstecken auf einen alten Port ist die Lösung und es besteht kein Zusammenhang zur neusten DVBViewer-Version. 

Edited August 28 by Bob.Dig

[Griga]

vor einer Stunde schrieb Bob.Dig:

Habe nun den Stick in seinen "alten Port" gesteckt, damit bestehen die Probleme nicht mehr.

 

Laut DVBViewer.log: 

10:53:51 Tune Request an Server

10:54:00 Antwort vom Server, also nach 9 Sekunden

 

Laut svcdebug.log: 

10:53:51: TCP Verbindung zum Client hergestellt (siehe unten und hier).

10:53:55: Tune Request vom Client. 

10:53:57:  Gerät initialisiert

10:54:00: Gerät getuned, Antwort an Client, also nach 5 Sekunden

 

Die Initialisierung und das Tunen des Gerätes gehen jetzt also wesentlich schneller

 

vor 1 Stunde schrieb Griga:

Dass es in einem Heimnetz 5 Sekunden dauert, bis der Server die TCP Request vom Client erhält, verstehe ich nicht.

 

Mir ist im Server-Log noch etwas aufgefallen: Die TCP-Verbindung wird nahezu gleichzeitig mit dem Absenden der Tune Request im Client hergestellt (den Zeitpunkt habe ich in den Aufzählungen ergänzt). Aber die Tune Request selbst erreicht den Server bei dir erst 4 oder 5 Sekunden später. Warum? Wer bummelt da so herum? Bei mir beträgt der Abstand zwischen dem Herstellen der Verbindung und dem Eintreffen der Tune Request mit einem Remote Client gerade mal 8 ms.

[Bob.Dig]

vor 1 Stunde schrieb Griga:

Wer bummelt da so herum?

Ich verwende ja eine Direktverbindung, also jeweils nicht das Default-Gateway. Vielleicht liegt es daran? Gibt es eine einfache Art außerhalb des DVBViewers das zu testen? In den Settings des Viewers ist jedenfalls alles schon auf die passende NIC ausgerichtet. 

Edited August 28 by Bob.Dig

[Bob.Dig]

Habe etwas experimentiert und meine PCIe-Karte von Haupauge verbaut. Damit war kein remote-gucken möglich. Bin dann wieder zurück auf die USB-Variante und auch damit war dann erst mal kein remote-gucken möglich, obwohl am "guten" USB-Port. Nach ein paar mehr Versuchen gab es dann auch wieder Bild.

Da mein Homeserver auch mein Internet bereit stellt und Hyper-V drauf läuft, nicht so einfach mal was zu ändern. PCIe-Slots habe ich auch nicht frei. 

 

 

svcdebugPCIe.log

[Griga]

Am 28.8.2025 um 14:23 schrieb Bob.Dig:

Ich verwende ja eine Direktverbindung, also jeweils nicht das Default-Gateway. Vielleicht liegt es daran?

 

Keine Ahnung. Die DMS-Log-Einträge für das Verbinden und das Eintreffen der Tune Request resultieren aus Event Handlern bzw. Callbacks, die aus der Netzwerk-Bibliothek aufgerufen werden. Was dazwischen passiert, ist für mich eine Black Box. Um dort mit dem Debugger durchzusteppen und zu schauen, wo es hängt, müsste ich das Phänomen hier reproduzieren können.

 

Am 28.8.2025 um 14:23 schrieb Bob.Dig:

Gibt es eine einfache Art außerhalb des DVBViewers das zu testen?

 

Weiß ich nicht. Wenn ich das Problem hätte, würde ich noch dies und das experimentell probieren, z.B. ob die 4 bis 5 Sekunden Verzögerung auch auftreten, wenn der Sender im DMS bereits wegen einer Aufnahme getuned ist. Normalerweise müsste das Bild im Client nach der Senderwahl sofort da sein.

 

Am 28.8.2025 um 14:23 schrieb Bob.Dig:

In den Settings des Viewers ist jedenfalls alles schon auf die passende NIC ausgerichtet. 

 

Auf welche Weise? Ohne (svc)hardware.xml fehlen mir solche und andere womöglich relevante Infos.

 

[Bob.Dig]

vor 19 Minuten schrieb Griga:

Auf welche Weise?

Das hier meinte ich, wobei das bei der TCP-Variante wohl keine Rolle spielen dürfte. 

Vermutlich auch keine Rolle spielt folgende Beobachtung: dass mir der Server nie unter seiner Direktverbindung angeboten wird, wenn ich ein neues RTSP Network Device anlegen will.

Werde bei Zeiten noch die (svc)hardware.xml hochladen.

[Griga]

vor 5 Stunden schrieb Bob.Dig:

Das hier meinte ich, wobei das bei der TCP-Variante wohl keine Rolle spielen dürfte. 

 

Das ist richtig.

 

vor 5 Stunden schrieb Bob.Dig:

Vermutlich auch keine Rolle spielt folgende Beobachtung: dass mir der Server nie unter seiner Direktverbindung angeboten wird, wenn ich ein neues RTSP Network Device anlegen will.

 

Eine leere Serverliste bedeutet hier, dass die UPnP-Servererkennung nicht funktioniert. Der Client sendet über alle vorhandenen (erkannten) Netzwerkadapter eine M-SEARCH Multicast-Suchanfrage (d.h. "an alle") und lauscht dann auf eine Server-Antwort. Das geht wie bei UPnP üblich via UDP über die Multicast-Adresse 239.255.255.250 und Port 1900. Sieht so aus, als wäre deine Direktverbindung nicht multicastfähig.

 

[Bob.Dig]

Am 31.8.2025 um 12:03 schrieb Bob.Dig:

Werde bei Zeiten noch die (svc)hardware.xml hochladen.

 

250901_1.zip

[Griga]

Ok, habe es mir angeschaut, konnte aber nichts entdecken, was für die Verzögerung relevant sein könnte.

 

Leider fehlt mir die praktische Erfahrung mit direkten Verbindungen sowie VMs, die ja meistens einen virtuellen Netzwerkadapter beinhalten, was auch Auswirkungen hat. Ist das bei dir auf dem Server-PC derjenige mit der 172.xxx.xxx.xxx Adresse?

 

[Bob.Dig]

@GrigaDie relevante Direktverbindung bei mir ist die 192.168.10.0/24. Virtualisierung sollte hier nicht mit reinspielen, weil weder DMS, noch Viewer virtualisiert sind, auch die Direktverbindung ist es nicht. 

Meine Vermutung aus diesem Thread ist es bis jetzt, dass bei mir die Timeouts deutlich erhöht werden müssten.

[Griga]

vor 1 Stunde schrieb Bob.Dig:

Virtualisierung sollte hier nicht mit reinspielen, weil weder DMS, noch Viewer virtualisiert sind, auch die Direktverbindung ist es nicht. 

 

Aber der DMS sieht den 172.xxx.xxx.xxx Adapter, wie dem Log zu entnehmen ist, lauscht deshalb auf Anfragen aus der Richtung, sendet darüber auch Multicast-Botschaften usw., und in der Routingtabelle von Windows dürfte er ebenfalls auftauchen... es gab hier schon einige Supportfälle, wo virtuelle Adapter eine Rolle spielten. Mit Multi-Homed Setups (d.h. PCs, die mit mehr als einem Netzwerk verbunden sind) ist nicht zu spaßen.

 

[Bob.Dig]

@GrigaHmm. Der Viewer hat aber wie gesagt die Direktverbindung sowohl für den Server als auch für die Hardware eingestellt. Und dass der DMS andere Netze auch nutzen "möchte" ist doch sicherlich kein Problem. Ich wüsste jetzt auch nicht, wie ich das von meiner Seite einschränken könnte.

 

Ich denke, dass es eher nicht mit meinem Problem zu tun hat, welches aktuell auch eher sporadisch auftritt bzw. durch mein TV-Verhalten kaum auffällt. Wenn ich nun diverse Adapter im DMS herausnehmen könnte, dann würde ich das machen. So etwas gibt es ja schon bei Web/UPnP, aber ich denke, da gibt es keinen Zusammenhang. 

 

Zitat

Mit Multi-Homed Setups (d.h. PCs, die mit mehr als einem Netzwerk verbunden sind) ist nicht zu spaßen.

Das gilt auf jeden Fall für SMB, was ich da schon bei mir erlebt habe...