Timeshift-Delegieren läuft nicht sauber (mit Windows Echtzeitschutz aktiv )

[dbotev]

 

Hallo,

Bin ich der Einzige mit dem Problem?

Mir ist seit einigen Tagen aufgefallen, dass der Tweak „Timeshift an DMS delegieren“  nicht sauber funktioniert.

Ich vermute -  das ist nach dem letzten größeren Windows- Update passiert.

 

 

Windows 10 Pro

Version 21H1

Installiert am     ‎14.‎04.‎2021

Betriebssystembuild      19043.1348

Windows Feature Experience Pack 120.2212.3920.0

 

 

Anbei meine Beobachtungen:

Meistens ist der DVBViewer der Meinung, dass keine Timeshift vorhanden wäre, obwohl der DMS eine Timeshift-Datei auf die Festplatte brav schreibt. Dementsprechend Vor- und Zurückspulen klappt nicht.

In manchen Fällen wird die Timeshift-Datei vom DMS weiter beschrieben (bzw. der Tuner bleibt belegt), obwohl der DVBViewer schon längst geschlossen wurde.

 

 

Ich habe alles Mögliche versucht, um auf die Spur zu kommen. Eine frische saubere Neuinstallation habe ich ebenso durchgeführt.

Siehe Support2.zip im nächsten Post!

 

 

Die Debug-Logs sehen aus meiner Sicht sauber aus.

 

 

Mir ist nur dies aufgefallen:

Sobald ich den Windows Echtzeitschutz deaktiviere, habe ich keine Probleme.

 

 

 

Manuelles Einrichten von Virenscanner-Ausnahmen löst das Problem nicht

(Ausgenommene Deteien: DVBVservice.exe, DVBViewer.exe, DVBVservice.exe; Ausgenommene Verzeichnisse: „C:\Program Files\DVBViewer“, „C:\Users\Public\Videos“, „C:\ProgramData\CMUV“)

 

 

Firewall komplett deaktivieren bewirkt ebenso keinerlei Verbessrung. Nur mit Echtzeitschutz-Inaktiv funzt alles bestens.

 

 

Mal sehen, ob noch jemand meine Beobachtungen bestätigt, bzw. reproduziert.

Edited December 7, 2021 by dbotev

[dbotev]

support2.zip

[dbotev]

Neue Erkenntnis: die Pop-up Warnung vor dem Setzten des Computers in Ruhezustand (z.B. am Ende einer Aufnahme) ist ebenso weg. Sobald ich den Echtzeitschutz deaktiviere, funktioniert die Warnung wieder.

 

[Griga]

Es sieht so aus, als ob der DVBViewer bei dir keine Nachrichten vom DMS mehr empfängt. Diese werden standardmäßig als UDP Multicast gesendet, weil es mehr als einen DVBViewer-Client im Netzwerk geben könnte.

 

Wenn dieser Mechanismus nicht funktioniert, betrifft es einiges:

• Die Fernsteuerung des DVBViewers mittels DVBViewer Controller App über den Media Server
• Die Aktualisierung der Timerliste im DVBViewer-Client, sofern unter Optionen -> DVBViewer Media Server vorgesehen.
• Die Aktualisierung der Aufnahmeliste im DVBViewer-Client, sofern unter Optionen -> DVBViewer Media Server vorgesehen.
• Die Aktualisierung des EPG im DVBViewer, falls er ihn vom DMS bezieht (außer beim DVBViewer-Start)
• Warung im DVBViewer, bevor der Media Server den PC (insbesondere nach einer Aufnahme) herunterfährt.
• Delegation von Timeshift an den Media Server, weil der DVBViewer nicht erfährt, dass die Aufnahme gestartet wurde.

Ein einfacher Test, um zu überprüfen, ob UDP Multicast funktioniert, besteht darin, im Browser auf dem Server PC die Request

 

http://127.0.0.1:8089/api/dvbcommand.html?target=PC-NAME&cmd=-x24

 

abzusenden (PC-NAME bitte an den Namen des PCs anpassen, auf dem der DVBViewer läuft). Daraufhin sollte sich das Optionen-Fenster des DVBViewers öffnen/schließen.

 

Was hier verwundert: Dass sich der Echtzeitschutz eines Virenscanners, der ja eigentlich Dateizugriffe überwachen soll, auf Netzwerkaktivitäten des DMS auswirkt. Der Zusammenhang erschließt sich nicht. Auf einem PC mit aktuellem Windows 10 (ohne optionale Updates) konnte ich das Problem auch nicht nachvollziehen.

 

Es gibt zwei Tweaks, an denen man probeweise drehen könnte, um zu sehen, ob sie sich auf das Problem auswirken:

• Im DVBViewer (Tweaker.exe starten): Adapter-IP für Media Server-Meldungen. Bestimmt die IP-Adresse des Netzwerk-Adapters, über den der DVBViewer auf eintreffende Meldungen vom zugeordneten Media Server lauscht. Der Standard 0.0.0.0 überlässt die Auswahl Windows. Hier könnte man den DVBViewer auf 127.0.0.1 festnageln.
• Im DMS (DMSTweaker.bat starten): DVBViewer-Clients Multicast-Botschaften senden. Veranlasst den Media Server, für die Kommunikation mit DVBViewer-Clients Multicast-Botschaften zu verwenden. Das Ausschalten dieser Option bewirkt das Senden von Broadcasts. Dies war die früher bis Media Server 2.1.0 verwendete Methode.

Mehr fällt mir dazu im Moment nicht ein...

 

[dbotev]

Danke für die schnelle Antwort, Griga!

http://127.0.0.1:8089/api/dvbcommand.html?target=MultimediaPC&cmd=-x24 ist der richtige Link bei mir.

Die Beobachtungen kann ich weiter bestätigen. Nur mit „Echtzeitschutz AN“ tut sich beim Link nichts.

Ich schaue weiter  wegen der Einstellungen und melde mich.

Gegebenenfalls probiere ich auf einem 2ten Rechner.

Ich verstehe immer noch nicht, warum kein anderer das Problem hat…das finde ich aber raus.

 

 

Edit: huh,  jetzt bin ich auf einem andren Laptop und ich habe folgendes ausprobiert:

 

http://192.168.1.3:8089/api/dvbcommand.html?target=MultimediaPC&cmd=-x24

 

192.168.1.3 = "IP MultimediaPC"

 

Funktioniert tadellos ... egal, ob auf dem MultimediaPC der Echzeitschutz an oder aus ist.

 

 

 

 

Edit2:

Über Tweaker.exe war eigentlich "127.0.0.1" bereits festgenagelt.  Ich habe heute meine reguläre Installation zurückgespielt.

Im Tweaker DMS „DVBViewer-Clients Multicast-Botschaften senden“ habe ich deaktiviert.  Dann tut sich aber ganz und gar nichts, egal ob Echtzeitschutz an,  oder aus ist.

Edited December 8, 2021 by dbotev

[dbotev]

...Edit3:

Das übliche:

-                sfc /scannow

-               DISM.exe /Online /Cleanup-image /Restorehealth

-                   netsh winsock reset

-                netsh advfirewall reset (und anschließend Neusetzen der Firewall Rules)

hilft nicht?

[Griga]

vor 4 Stunden schrieb dbotev:

Über Tweaker.exe war eigentlich "127.0.0.1" bereits festgenagelt.

 

Was ist, wenn du dort 192.168.1.3 einträgst? Der DMS sendet seine Botschaften über alle verfügbaren Adapter.

 

[dbotev]

Ja, genau das habe ich parallel zu Deinem Letzten Post ausprobiert und das Kommando x24 über

"http://192.168.1.3:8089/api/dvbcommand.html?target=MultimediaPC&cmd=-x24" erzwungen.

 

Jetzt wird es interessant …voller Chaos eigentlich:

Echtzeitschutz am DMS Rechner (192.168.3) AN:

Kommando x24 über 192.168.1.3 => Kein Effekt

Kommando x24 über Client 192.168.1.24 => Funktioniert

Delegieren Timeshift  über 192.168.1.3 => Funktioniert nicht

Warnung  „DMS –PC Ausschalten“ => Funktioniert nicht an beiden Rechnern

 

Echtzeitschutz am DMS Rechner (192.168.3) AUS:

Kommando x24 über 192.168.1.3 => Funktioniert

Kommando x24 über Client 192.168.1.24 => Funktioniert

Delegieren Timeshift  über 192.168.1.3 => Funktioniert nicht

Warnung  „DMS –PC Ausschalten“ => Funktioniert nicht an beiden Rechnern

[dbotev]

So, ich habe den Windows Defender deaktiviert und anschließend komplett  über CMD „gesäubert“:

 

cd "%PROGRAMFILES%\Windows Defender"

MPCMDRUN.exe -RemoveDefinitions -All

 

Jetzt funktioniert das Delegieren problemlos

 

Mal sehen was passiert, sobald die neusten Signature-Updates eingeholt werden…

 

MPCMDRUN.exe –SignatureUpdate

 

…und nach dem Update - geht wieder gar nichts ?grrr

[Griga]

vor 8 Stunden schrieb dbotev:

und nach dem Update - geht wieder gar nichts

 

Sieht so aus, als wären DMS/DVBViewer oder auch der UDP Netzwerkverkehr höchstpersönlich aufgrund einer Signaturerkennung verdächtig, worauf letzterer unterbunden wird.

 

Ein möglicher Ansatzpunkt wären Defender-Richtlinien. Es gibt Hinweise im Web auf Einstellungen die relevant sein könnten (z.B. auf dieser Seite nach UDP suchen). Hier erfährt man, wie man den Richtlinien-Editor (gpedit.msc) unter Windows 10 verfügbar macht, falls es sich nicht um eine Pro-Version handelt.

 

 

[dbotev]

Danke, das probiere ich am Abend aus. Wieder helles Licht?

Anbei - hier die deutsche Quelle.

Das sollte die gemeinte Einstellung sein:

Richtlinie-Einstellung: EnableNetworkProtection/DisableDatagramProcessing

"Um diese Funktionalität zu deaktivieren, legen Sie diese Konfiguration auf "$true" fest."

[dbotev]

Wow, das war ein Kampf!

Ich glaube, dank der letzten Empfehlung von Griga haben wir es hingekriegt.  BESTEN DANK!!!

Anbei meine Lösung:

PowerShell als Admin starten

„Get-MpPreference“ eingeben und den Wert von „DisableDatagramProcessing“ überprüfen.

Bei mir war der Wert auf FALSE gesetzt…sprich „UDP Verarbeiten“ war aktiv.

„Set-MpPreference -DisableDatagramProcessing $true“ in die Konsole eingeben

Rechner-Neustart

Gegebenenfalls den Wert vom „DisableDatagramProcessing“ erneut überprüfen und sicherstellen, dass dieser erfolgreich auf TRUE gesetzt wurde.

 

 

Jetzt bleibt noch die Frage: Bin ich wirklich der einzige mit dem Problem?  

@Griga: bitte, könntest Du auf dem Testrechner den Wert von „DisableDatagramProcessing“ überprüfen?

P.S: Jetzt gehen sogar beide Abfragen problemlos:

http://127.0.0.1:8089/api/dvbcommand.html?target=MultimediaPC&cmd=-x24

http://192.168.1.3:8089/api/dvbcommand.html?target=MultimediaPC&cmd=-x24

 

 

  

Edited December 9, 2021 by dbotev

[Griga]

vor 16 Stunden schrieb dbotev:

@Griga: bitte, könntest Du auf dem Testrechner den Wert von „DisableDatagramProcessing“ überprüfen?

 

Steht auf False. Trotzdem funktioniert alles.

 

Bleibt die Frage, was den Defender bei dir an dem Netzwerkverkehr stört. Viel sendet der DMS ja nicht. Für delegiertes Timeshift signalisiert er nur den Start/Stopp der Aufnahme durch die Zeichenkette RST (Recording Start/Stop) plus die Ganzzahl ID der Aufnahme. Das ist alles.

 

[dbotev]

Hm…habe nachgedacht. UAC (User Account Control) ist bei mir z.B. aus…und ich habe 2 DVBViewer Client Installationen auf einem Rechner, damit ich gelegentlich neue Sachen ausprobieren kann.

Da die Frage mich aus Sicherheitsgründen interessieren würde, werde ich auf jedem Fall nachbohren und versuchen das Verhalten auf einem 2ten Rechner zu reproduzieren und die Ursache melden.

Das Thema kann man auf jedem Fall „Gelöst“ markieren und man muss auf jedem Fall anmerken, dass sich hier um kein DVBViewer Bug handelt. Danke für die Unterstützung!