h0ly0ne Posted August 1, 2020 Share Posted August 1, 2020 (edited) Ich habe dieses Problem jetzt schon etwas länger - und auch mit einigen Hardware Setups durchgemacht - also vermute ich eher ein prinzipielles Problem im Media Server (also in den anderen Komponenten) - bin aber natürlich für jeden Tipp mehr als dankbar. Im Detail geht es darum das sich der Media Server bei schnellen Programmwechselvorgängen (egal ob der Client ein DVBViewer Client und/oder ein Hardware-Client im Panasonic TV Gerät ist) ohne Meldung in den Log-Files verabschiedet. Man sieht den Programmwechselvorgang noch im "svcdebug.log", jedoch wird weder ein Feedback vom Service geliefert (Clients zeigen kein Signal bzw. kein Server verfügbar an) noch stirbt der Prozess an sich (sprich er läuft weiter und die Tray Tools zeigen einen noch laufenden Media Server an). Um das Thema etwas in den Griff zu bekommen habe ich mir ein kleines Tool geschrieben das über das WebInterface abfragt und bei keiner Antwort den Windows-Service durchstartet. Ist zwar ein netter Workaround - jedoch wäre es mal nett die wirkliche Ursache des Problems zu finden. Vielleicht hätte ja jemand einen Tipp wie ich in den Log Files etwas mehr entlocken kann - reproduzierbar ist der Fehler in wenigen Minuten - ich muss nur wild durch die Kanäle zappen. Zusatzinformationen: Betriebssystem: Windows Server 2019 oder Windows 10 (am Server) - x64 Version Server: DVBViewer Media Server 2.1.6.1 Version Software Client: DVBViewer Pro V6.1.6.1 Version Hardware Client: Panasonic TX-65FXW784 Plugins: keine bzw. ein CAM Modul Plugin (Fehler aber mit und ohne Plugin reproduzierbar) Quelle: DVB-C über OctopusNET V2 C2 (über Sat>IP) oder alternativ Haupauge PCTV tripleStick HD 292e (über Device Driver) (Fehler aber mit beiden Quellen reproduzierbar) Informationen zur Support.zip: * der Crash (wo kein Feedback mehr vom Service kommt) passierte exakt an dem Punkt wo im Log nichts mehr protokolliert wird * es wird weder Feedback vom WebService noch über Sat>IP geliefert (sprich Media Server wird nicht mehr erkannt) support.zip Edited August 1, 2020 by h0ly0ne Quote Link to comment
Griga Posted August 1, 2020 Share Posted August 1, 2020 3 minutes ago, h0ly0ne said: Im Detail geht es darum das sich der Media Server bei schnellen Programmwechselvorgängen (egal ob der Client ein DVBViewer Client und/oder ein Hardware-Client im Panasonic TV Gerät ist) ohne Meldung in den Log-Files verabschiedet. Das könnte etwas mit der im Media Server verwendeten DVB-Hardware zu tun haben, die du verschweigst. Eine support.zip wäre nicht schlecht. Quote Link to comment
h0ly0ne Posted August 1, 2020 Author Share Posted August 1, 2020 Sorry - hatte noch eben die Daten ergänzt da hast du schon reagiert - sollten jetzt im Topic mitbeschrieben sein. Das Thema mit der support.zip sehe ich mir gerade an - folgt auf dem Fuße. Quote Link to comment
Griga Posted August 2, 2020 Share Posted August 2, 2020 6 hours ago, h0ly0ne said: reproduzierbar ist der Fehler in wenigen Minuten - ich muss nur wild durch die Kanäle zappen. Wie genau - man muss 5 Minuten lang ununterbrochen wild zappen? Das ist ja richtig Arbeit Bekannt ist ein solches Problem nicht. Ich habe es mit einem DVBViewer-Client via localhost und einer DVBSky USB Box probiert, konnte es jedoch nicht reproduzieren. Allerdings habe ich nur eine Minute lang mit Favorit Plus/Minus wild durch die Kanäle geschaltet, dann hatte ich keine Lust mehr... Hast du es schon mal mit deaktivierter Sicherheitssoftware getestet? Du könntest auch probieren, den DMS als Anwendung laufen zu lassen: Service stoppen, dann DVBVservice.exe starten, worauf er mit einem Fenster auf dem Desktop erscheint. Dabei gibt es ein paar Einschränkungen - insbesondere erkennen Tray Tool und Optionen nicht mehr, dass der DMS läuft - aber für Testzwecke kann man das mal machen und in deinem Fall feststellen, ob der Prozess wirklich festhängt (d.h. das Fenster sich nicht mehr normal schließen lässt) oder der DMS nur den Netzwerkbetrieb einstellt. Wenn er festhängt, wäre noch festzustellen, ob er das mit CPU-Last (aufgrund Endlosschleife) oder wirklich unbegrenzt tut. Auf der Netzwerkebene wird gerne bis zu einem Timeout auf irgendwas gewartet, so dass ein Aufruf z.B. erst nach 30 Sekunden zurückkehrt. 6 hours ago, h0ly0ne said: der Crash (wo kein Feedback mehr vom Service kommt) passierte exakt an dem Punkt wo im Log nichts mehr protokolliert wird Leider gibt das nicht unbedingt die Stelle an, an der es passiert, weil bei einem Crash gepufferter Text verlorengehen kann. Quote Link to comment
h0ly0ne Posted August 2, 2020 Author Share Posted August 2, 2020 Hallo nochmal, ich habe den Media Service nun als Applikation laufen lassen und das Verhalten wieder provoziert - vom Gefühl her gelang es mir jetzt nicht so einfach (musste knappe 30 Minuten Programme durchzappen bis der Zustand wieder auftrat - war aber jetzt kein wildes gezappe - sondern alle 15-30 Sekunden Kanal wechseln). Vom Verhalten konnte ich folgendes festhalten: Das Fenster der Applikation bleibt aktiv und kann herumgezogen und in der Größe verändert werden. Sobald man das Fenster jedoch schließen will hängt sich die Applikation und der dahinterliegende Prozess weg und kann nur über Task-Manager gekillt werden (um danach problemlos wieder gestartet zu werden). Es ändert sich weder an der Speicherlast (~30MB) noch an der CPU Auslastung (0%) etwas wenn der "Crash" eintritt. Es stellt sich nur die komplette Kommunikation tot (sprich kein Response mehr auf Sat>IP Requests noch über das WebInterface) und im svcdebug.log wird ab dieses Moment auch nichts mehr protokolliert. Die normale Netzwerk- kommunikation mit der Maschine ist aber nach wie vor gegegeben - also scheint der Netzwerkstack hier nicht davon betroffen zu sein. Wenn man die Applikation über den Task-Manager beendet bzw. mit X schließt wird noch folgende Meldung im Log aufgenommen: Zeitpunkt ab dem Kommunikation eingestellt wird -> "03.08.20 00:04:11.703 PLAY 200 addpids=6331" Zeitpunkt wenn Applikation beendet + abgeschossen wird -> "03.08.20 00:15:47.016 End App ------------------------------------------------------------" Im Event-Log sieht es auch sehr solide und still aus - keinerlei Information das irgendwo zu diesem Zeitpunkt etwas schiefläuft. Grüße, Oliver Quote Link to comment
Griga Posted August 3, 2020 Share Posted August 3, 2020 Und was ist mit der "Kaspersky Total Security"? Vielleicht nimmt die einen DDos-Angriff an, wenn du so wild rumzappst, und blockiert weitere Verbindungen. Bitdefender lässt z.B. den DVBViewer als Sat>IP-Client überhaupt nicht zu, sofern man nicht an einer schwer zu findenden Stelle eine Ausnahme einrichtet. Quote Link to comment
h0ly0ne Posted August 3, 2020 Author Share Posted August 3, 2020 Hallo nochmal, ich hatte die Situation eigentlich 1:1 auf einem Windows Server 2019 reproduziert - und dort ist als einzige Schutzlösung der Windows Defender installiert (und dieser ist deaktiviert) - also schließe ich die Kaspersky Suite zu 99,9% aus. lg, Oliver Quote Link to comment
Griga Posted August 3, 2020 Share Posted August 3, 2020 Ich werde es bei nächster Gelegenheit noch mal unter anderen Bedingungen testen. Mit zwei PCs via WLAN und einem Media Server als Quelle für einen zweiten. Ehrlich gesagt hat es jedoch keine besondere Priorität, solange das Problem nicht von verschiedenen Seiten gemeldet wird und sich hier nicht mit vertretbarem Aufwand reproduzieren lässt. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.