Jump to content

manuelle Aufnahmen im DVBViewer lässt sich nicht stoppen


x112

Recommended Posts

Wenn ich ausnahmsweise mal über den DVBViewer eine Aufnahme starte, funktioniert das nicht immer wie erwartet.

Mit dem DVBVIerwer auf dem Mediaserver Rechner funktioniert es. Die Aufnahme taucht im Mediaserver auf und sie lässt sich auch im DVBViewer stoppen.

Wenn ich das aber im DVBViewer auf dem anderen Rechner (lokales Netzwerk) versuche, startet die Aufnahme erst beim zweiten Klick auf Aufnehmen. Mit einem weiteren Klick auf Aufnehmen wird die Aufnahme zwar auf dem Mediaserver gestoppt, der DVBViewer bekommt das aber nicht mit und denkt immer noch das die Aufnahme läuft. Beim Beenden frägt er z.B.: nach ob die laufende Aufnahme gestoppt werden soll.

Ist in meinen Einstellungen was falsch?

support_ms.zip ist vom Mediaserver Rechner, support_remote.zip ist vom DVBViewer Rechner der das Problem hat.

support_MS.zip

support_remote.zip

Link to comment

Womöglich handelt es sich um ein netzwerktechnisches Kommunikationsproblem zwischen DMS und DVBViewer. Hier wurde etwas Ähnliches vor kurzem  untersucht. Insbesondere kann man mit diesem Test ermitteln, ob die Botschaften des DMS zum DVBViewer-Client durchkommen.

 

Das Ergebnis war eine Umstellung der Kommunikation von Broadcast auf Multicast, das (hoffentlich) zuverlässiger funktioniert. In zwei Fällen hat es sich bereits bewährt. Es wird bald ein Bugfix-Release mit dieser Neuerung geben.

 

Link to comment

Mit diesem "Befehl" auf dem MediaService Rechner lässt sich der DVBViewer auf dem anderen Rechner problemlos steuern: http://localhost:8089/api/dvbcommand.html?win10&cmd=-x24.

Wenn dann die Umstellung auf Multicast kommt werde ich das Recording Problem noch mal testen. Bei mir könnte bei Broadcast ein Befehl über zwei Wege beim Client ankommen: einmal über ein Crossover Ethernet Kabel und einmal über WLAN. In den host Dateien habe ich immer die LAN IP eingetragen, damit nichts den Umweg über den WLAN Router nimmt.

Allerdings hat ein simples WLAN Abschalten am Verhalten nichts geändert.

 

Link to comment

Es könnte theoretisch auch an anderer Stelle haken.... der DVBViewer verwendet das DMS API, um dort einen Timer zu erzeugen (HTTP, Webserver) -> DMS signalisiert allen DVBViewer Clients, dass sich die Timer/Aufnahmeliste geändert hat (UDP Broadcast) -> DVBViewer holt sich über das DMS API die neue Timer/Aufnahmeliste  (HTTP, Webserver).

 

Ich stelle dir zwecks Test via PM eine Vorab-Version zur Verfügung...

 

Link to comment

Mit der Testversion hat sich am Verhalten nichts geändert. Mir ist allerdings aufgefallen das die Aufnahme schon beim ersten Klick auf den Aufnahmebutton startet, es wird nur vom DVBViewer nicht erkannt. Beim zweiten Start wird dann eine zweite Aufnahme gestartet und korrekt angezeigt. Diese zweite lässt sich auch vom DVBViewer aus beenden. Aber es wird immer noch Recording angezeigt. 

Die allererste Aufnahme lässt sich nur auf dem Server beenden.

Ich hoffe man sieht das im Logfile.

svcdebug.zip

Link to comment

Das Log spiegelt wieder, was bei dir passiert bzw. nicht passiert. Es fehlen die /api/timerlist.html Aufrufe, die der DVBViewer als Reaktion auf die Broadcasts/Multicasts des DMS durchführen sollte - insbesondere der Aufruf nach dem Start der Aufnahme. Allerdings verrät das Log nicht, warum sie ausbleiben.

 

Bei der Client-Konfiguration fällt die Adresse des DMS auf: videoserver:8089. Normalerweise steht da eine IP-Adresse wie 192.168...:8089. Kannst du sie dort probeweise eintragen? Wenn der DVBViewer einen Broadcast/Multicast erhält, vergleicht er die IP des Absenders mit der konfigurierten Adresse, um zu ermitteln, ob es sich um "seinen" DMS handelt. Ich vermute, das geht bei dir schief, weil an der Stelle keine Namensauflösung stattfindet.

 

Mit dem oben angegebenen Testbefehl kann dieses Problem nicht auftreten, weil hierbei der übertragene Name des Ziel-PCs das Filterkriterium ist und nicht die Adresse des Absenders.

 

Link to comment

Auch mit dem neuen Client hat sich nichts geändert. Ich werde jetzt mal auf beiden Systemen die WLAN Verbindung deaktivieren, so das es nur noch einen Weg gibt.

Link to comment

Auch wenn es nur noch eine Verbindung gibt, funktioniert das Timer starten/stoppen nicht remote.

Hier ein neues Log: Start auf Viewer Client, Stopp auf Server (da der Viewer von der Aufnahme nichts weiß).

svcdebug.zip

Link to comment

Ich werde nächste Woche mal auf meinen Firmen Notebook DVBViewer installieren und das damit testen. Kann aber ein paar Tage dauern bis ich dazu komme.

Link to comment

Ich habe es hier mit einem Eintrag in der hosts Datei probiert

 

192.168.xxx.xxx mediaserver

 

und den Remote-DVBViewer auf mediaserver:8089 konfiguriert. Das klappt mit manuellen Aufnahmen und der DVBViewer-Testversion.

 

Link to comment

Mit den neuen Versionen funktioniert das jetzt auch bei mir wieder zuverlässig. Egal ob man die richtige IP auswählt oder einen Namen eingibt.

 

Link to comment
  • 3 weeks later...

Habe gestern mal von DMS 2.0.4 auf 2.1.1 geupdatet. Seit dem habe ich das selbe Problem. Das verhalten ist auf 2 Client´s vorhanden. Habe dann wieder auf DMS 2.0.4 gedowngraded und es funktioniert wieder ganz normal. Hat da noch einer eine Idee? Würde gerne DMS 2.1.1 verwenden.

Link to comment

Ich habe das gerade noch mal geprüft: mit dem aktuellen DVBViewer/Mediaserver funktioniert das bei mir jetzt sogar mit Multicast und Broadcast. Da Multicast der Default ist, lasse ich das auf Multicast stehen. Beim Viewer habe ich aktuell die IP Adresse stehen, damit wirklich sicher ist das die LAN Verbindung und nicht der WLAN Umweg genommen wird.

Link to comment

Das Changelog habe ich gelesen. Aber da der DVBViewer ja unter dem Menu Optionen -> DVBvier Mediaserver den DMS anzeigt, dachte ich das ja alles o.k. ist.

Wenn ich in dem Pulldownfenster den DMS Server auswähle, füllt er die anderen Felder ja automatisch, also da steht dann ja auch die richtige IP Adresse incl. Port.

 

Die favoriten und timer etc werden ja auch übernommen, nur das manuelle Starten einer Aufnahme funktioniert nicht.

 

Werde dann noch einmal den DMS 2.1.1 installieren und mit der "alten" broadcast Methode testen. Mein HTPC hat nur eine LAN Karte und der DMS Server auch.

Link to comment

Ich wüsste gerne, warum bei manchen die DMS -> DVBViewer-Botschaften nur per Multicast funktionieren, bei manchen nur per Broadcast und bei anderen (wie bei mir) sowohl als auch. Muss irgendwie am Netzwerk, am Router oder was weiß ich liegen. Ich hoffe, es tauchen keine Anwender auf, bei denen weder noch geht. ;)

 

Ich glaube, ich habe zu alte Hardware. Vieles aus der Vista-Ready-Zeit, irgendwo ausrangiert und dann für lau bei mir gelandet. Damit funktioniert immer alles, so dass ich Probleme nicht nachvollziehen kann. Für Testzwecke müsste ich eigentlich einen topaktuellen Gerätepark haben, die ganzen tollen Sachen, die sich Anwender kaufen und mit denen alles mögliche schiefgeht. Kostet aber leider....

 

Link to comment

Meine 2 Systeme haben auch nur eine LAN Karte, allerdings finden sie sich auch über den WLAN Router. Vielleicht ist es bei bigp4 ja ähnlich. In die Theorie passt nur nicht das jetzt bei mir Broadcast und Multicast geht. Da müsste man wohl die Netzwerkpakete ganz genau analysieren aber LAN auf so tiefer Ebene war mir schon immer ein Graus.

Link to comment
  • 2 weeks later...

Als Info,

bei mir tritt exact dieses Problem genauso auf, allerdings nur auf einem Client.

Nach Änderung per tweaker auf Broadcast läuft auch dieser Client wieder.

Habe auf dem Client DVBViewer testweise mal neu installiert, Firewall aus... keine Änderung.(Der Testbefehl funktionert dann auch nicht)

Habe das ganze mal mit Wireshark auf dem Client mitgeschnitten.

 

http://localhost:8089/api/dvbcommand.html?target=HTPC-ALEX&cmd=-x24

auf dem Server

 

per Broadcast (Menü öffnet sich)

 

Frame 1491: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) on interface 0
Ethernet II, Src: AsustekC_7c:22:fa (08:60:6e:7c:22:fa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.6.101, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 62554, Dst Port: 1901
Data (29 bytes)

0000   ff ff ff ff ff ff 08 60 6e 7c 22 fa 08 00 45 00   ÿÿÿÿÿÿ.`n|"ú..E.
0010   00 39 7d a6 00 00 80 11 f6 00 c0 a8 06 65 ff ff   .9}¦....ö.À¨.eÿÿ
0020   ff ff f4 5a 07 6d 00 25 4f fa 44 56 42 56 55 50   ÿÿôZ.m.%OúDVBVUP
0030   44 41 54 45 20 43 4d 44 20 48 54 50 43 2d 41 4c   DATE CMD HTPC-AL
0040   45 58 20 2d 78 32 34                              EX -x24

 

per Multicast (Menü geht nicht auf)

 

 

Frame 186: 71 bytes on wire (568 bits), 71 bytes captured (568 bits) on interface 0
Ethernet II, Src: AsustekC_7c:22:fa (08:60:6e:7c:22:fa), Dst: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
Internet Protocol Version 4, Src: 192.168.6.101, Dst: 239.255.255.250
User Datagram Protocol, Src Port: 52812, Dst Port: 1901
Data (29 bytes)

0000   01 00 5e 7f ff fa 08 60 6e 7c 22 fa 08 00 45 00   ..^.ÿú.`n|"ú..E.
0010   00 39 5a 5b 00 00 01 11 a8 51 c0 a8 06 65 ef ff   .9Z[....¨QÀ¨.eïÿ
0020   ff fa ce 4c 07 6d 00 25 86 0d 44 56 42 56 55 50   ÿúÎL.m.%..DVBVUP
0030   44 41 54 45 20 43 4d 44 20 48 54 50 43 2d 41 4c   DATE CMD HTPC-AL
0040   45 58 20 2d 78 32 34                              EX -x24

 

 

Der Multicast kommt also an, der DVBViewer bekommt den aber warum auch immer nicht mit.

Neuinstall, Firewall on off alles getestet, ändert nichts.

Hab mal nach geschaut SSDP Dienst läuft.

 

Wenn ich den UPNP Server de/aktiviere sehe ich den auf dem Client bzw. nicht.(Das läuft ja über SSDP ).

 

 

Edited by jasch
Link to comment

Danke für die gründliche Untersuchung.

 

Gibt es auf dem Client-PC eine Besonderheit, die das erklären könnte? Vielleicht mehr als einen aktiven Netzwerkadapter (z.B. LAN + WLAN), so dass der DVBViewer bei Multicast über den falschen auf eintreffende Botschaften lauscht?

 

Bei UPnP wird nämlich explizit für jeden vorhandenen Adapter ein Socket erzeugt, für den Empfang der speziellen DMS-Botschaften jedoch nicht.

Link to comment

Nein, nur ein aktiverter und verbundener Netzwerkadapter auf diesem Client.

Selbes Win10 wie überall, ausser DVBViewer, Madvr, Ambibox etc. nichts installiert.

(werde falls ich zeit finde, aber mal neuinstallieren am We)

Lustigerweise funktionert mein ArbeitsPC einwandfrei, bei dem funkt WOL per DVBViewer nicht da mehere Karten und Subnetze.

Edited by jasch
Link to comment

Fragt sich, warum es hier funktioniert, dort nicht... es muss irgendeinen Unterschied im System (bzw. dessen Einstellungen) geben.

 

Internet-Recherchen ergeben zwei Ansatzpunkte:

 

(1) Die Routing-Tabelle, die man mittels Eingabeaufforderung

 

route print

 

abrufen kann. Die lässt sich auch irgendwie ändern. Ich habe allerdings zu wenig Erfahrung damit, um das interpretieren zu können.

 

(2) Das Default-Interface (= Default-Netzwerkadapter) für Multicast-Empfang. Wie gesagt spezifiziert der DVBViewer den Adapter für den Empfang der DMS-Botschaften nicht explizit, sondern gibt als "Wildcard" die Adresse 0.0.0.0 an. Angeblich nimmt Windows dann das Default-Interface, das theoretisch auch der Loopback-Adapter ("localhost") sein kann. Ich bin mir nicht ganz klar darüber, was in dem Fall passiert.  Mittels Eingabeaufforderung liefert

 

netsh interface ip show joins

 

wie viele "Multicast-Mitgliedschaften" (Verweise) pro Interface und Multicast-Adresse vorliegen. Für den DVBViewer ist 239.255.255.250 von Interesse. Bei einem laufendem DVBViewer, der als DMS-Client konfiguriert ist, erhalte ich folgende Ausgabe (reduziert auf 239.255.255.250):

Schnittstelle 1: Loopback Pseudo-Interface 1
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    4  Ja    239.255.255.250

Schnittstelle 12: Drahtlosnetzwerkverbindung
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    5  Ja    239.255.255.250

Ohne laufenden DVBViewer gibt es nur jeweils 2 Verweise (vermutlich vom WMP Hintergrund-Dienst). Nehme ich im DVBViewer den Haken bei Optionen -> DVBViewer Media Server -> Unterstützung für den DVBViewer Media Server raus, sinken die 5 Verweise für die Drahtlosnetzwerkverbindung auf 4. Also hat sich der DVBViewer dort für den Empfang spezieller DMS-Botschaften eingeklinkt, oder anders gesagt, das ist für Windows das Default-Interface.

 

Es wäre von Interesse, wie das Experiment bei nicht funktionierender Multicast-Methode ausgeht...

 

Link to comment

Ich glaube 0.0.0.0.0 heißt das auf allen Schnittstellen gelauscht wird. Bei mir funktionieren jetzt ja beide Methoden, aber trotzdem hier meine netsh Ausgabe:

Die Kommunikation soll über vEthernet LAN laufen und geht auch über vEthernet WLAN. Hier scheint der DVBViewer 2 Verweise auf vEthernet LAN zu erzeugen.

Mit laufenden DVBViewer:

Schnittstelle 1: Loopback Pseudo-Interface 1
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

Schnittstelle 11: WLAN
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

Schnittstelle 10: vEthernet (Standardswitch)
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

Schnittstelle 18: vEthernet (LAN)
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    5  Ja    239.255.255.250

Schnittstelle 13: vEthernet (Intern)
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

Ohne:

Schnittstelle 1: Loopback Pseudo-Interface 1

Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    2  Ja    239.255.255.250

Schnittstelle 11: WLAN
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    2  Ja    239.255.255.250

Schnittstelle 10: vEthernet (Standardswitch)
0                    2  Ja    239.255.255.250

Schnittstelle 18: vEthernet (LAN)
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

Schnittstelle 13: vEthernet (Intern)
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    2  Ja    239.255.255.250

 

Edited by Griga
Code Tags ergänzt
Link to comment
3 hours ago, x112 said:

Ich glaube 0.0.0.0.0 heißt das auf allen Schnittstellen gelauscht wird.


Soweit klar. Aber als Multicast Client muss der DVBViewer nicht nur lauschen, sondern auch unter Angabe des Interface und der Multicastadresse eine Art Mitgliedschaft in einer Gruppe anmelden (IP_ADD_MEMBERSHIP), weil der Netzwerkadapter sonst die Pakete eventuell nicht durchleitet. Das ist eine Art Filtermechanismus. Auf diese Mitgliedschaft bezieht sich die Ausgabe von

 

netsh interface ip show joins

 

Die Anmeldung führt der DVBViewer beim Lauschen auf die speziellen DMS-Botschaften ebenfalls mit 0.0.0.0 durch, d.h. gibt kein bestimmtes Interface an, und die Frage ist, wie Windows das intern organisiert und welche Folgen es hat. Soweit ich bis jetzt weiß, wählt Windows dann ein Standard-Interface.


Der DVBViewer arbeitet auch im Zusammenhang mit UPnP und der Sat>IP-Server-Erkennung als Multicast-Client. Das ist anders organisiert: Er meldet sich explizit bei jedem lokalen Interface an (einschließlich dem Loopback-Adapter 127.0.0.1). Da bei  @jasch  UPnP funktioniert, der Empfang der speziellen DMS-Multicast-Botschaften jedoch nicht (siehe hier), nehme ich an, dass in dieser Richtung der Hund begraben liegt.

 

Von Interesse ist deshalb weniger die netsh-Ausgabe mit und ohne laufendem DVBViewer, sondern vielmehr mit und ohne den Haken bei Optionen -> DVBViewer Media Server -> Unterstützung für den DVBViewer Media Server. Der entscheidet nämlich, ob der DVBViewer die speziellen (Broadcast- oder Multicast-)Botschaften des Media Servers empfängt.

 

Link to comment

Zwischen Mediaserver Unterstützung an oder aus gibt es nur beim WLAN einen Unterschied, an den anderen Interfaces ändert sich nichts.

Ohne MS Unterstützung:

Schnittstelle 11: WLAN
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    2  Ja    239.255.255.250

 

Mit MS Unterstützung:

Schnittstelle 11: WLAN
Bereich       Verweise  Letzte  Adresse
----------  ----------  ----  ---------------------------------
0                    3  Ja    239.255.255.250

 

Seltsamerweise bleibt der DVBViewer auch ohne den Haken bei MS Unterstützung noch bedienbar. Früher hat da der Start des DVBViewer immer deutlich länger gedauert und dann ging gar nichts. Kommt das durch die Multicast Unterstützung oder ist das ein Bug und hier wird gar nicht die MS Unterstützung abgeschaltet?

Wenn ich die WLAN Verbindung trenne, geht der Viewer immer noch. Auf dem RS ist zur Zeit die Multicast Variante aktiv.

 

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...