Nach neuem Rechner Probleme mit dem Umschalten

[agio]

Hallo,

 

ich nutze den DVBViewer Media Server schon seit langem und bin sehr zufrieden.

 

Ich habe nun einen neuen Rechner als Server unter Windows 11 in Betrieb genommen und es stellt sich folgendes Problem.

 

Beim Umschalten am Client wird manchmal die Verbindung zum Server beendet und dann vom Kodi-Client wieder aufgebaut. Dies passiert anscheinend, wenn nur ein Client aktiv ist und einige Zeit nicht umgeschaltet hat.

 

In den Energieoptionen des Rechners/Netzwerkarte habe ich schon einiges ausprobiert, aber komme nicht wirklich weiter.

 

Hat einer einen Tipp, wo ich noch schauen kann.

 

Gruß

 

Severin

support.zip

[Griga]

vor einer Stunde schrieb agio:

Beim Umschalten am Client wird manchmal die Verbindung zum Server beendet und dann vom Kodi-Client wieder aufgebaut.

 

Du meinst eine Senderumschaltung? Inwiefern ist das Beenden und der Neuaufbau der Verbindung problematisch? Dauert es zu lange?

 

Geht der Server-PC vielleicht ungewollt in den Energiesparmodus? Es gibt am Ende deines svcdebug.log ein solches Ereignis. Der PC schläft um 12:35:10 Uhr kurz nach dem Tunen eines Senders ein und wacht um 12:36:02 wieder auf.

 

Hier könnte in den Media Server-Optionen (SvcOptions.exe) das Einschalten von "Web/UPnP -> PC-Energiesparmodus durch Anwender, andere Programme und Energie-Einstellungen verhindern, solange Daten gesendet werden" helfen. Bei dir ist die Option aus.

 

P.S. Es könnte aber auch an Windows 11 liegen. Dann nützt die oben erwähnte Option wahrscheinlich nichts. Hier gibt es bereits ein Thema mit einem solchen Verdacht.

 

Edited February 16 by Griga
Ergänzung

[agio]

Hallo Griga,

 

vielen Dank für die schnelle Antwort.

 

Der Kodi-Client springt dann ins Menü und erst nach ca. 30 Sekunden kann man wieder TV schauen starten. (Nicht der beste WAF).

 

Die Media Server-Option habe ich nun mal eingestellt und werde schauen ob es hilft.

 

Es sieht wirklich so aus, daß der Server beim Umschalten in den Energiesparmodus geht. Wenn man den Client direkt bei dem Umschaltproblem ausschaltet (z.B. aus Frust), ist der Server wirklich im Energiesparmodus. Das verlinkte Thema scheint recht gut zu passen.

 

Gruß

 

Severin

 

[Griga]

Ich fürchte, da hilft im Moment nur, den Server-PC so zu konfigurieren, dass er niemals von alleine in den Energiesparmodus geht. Es handelt sich hier um den sogenannten "Idle Timeout", also die Zeit ohne Benutzeraktivität, nach der das System einschläft.

 

[agio]

Hallo,

 

die Media Server-Option hält den Server wach und daher kommt es nicht mehr zu Problemen beim Umschalten, wenn auf einem anderen Rechner das Web-Frontend läuft.

Hier läuft noch eine kleine W10 VM auf der ich das Frontend gestartet habe.

 

vor 5 Stunden schrieb Griga:

Hier könnte in den Media Server-Optionen (SvcOptions.exe) das Einschalten von "Web/UPnP -> PC-Energiesparmodus durch Anwender, andere Programme und Energie-Einstellungen verhindern, solange Daten gesendet werden" helfen. Bei dir ist die Option aus.

 

Ich werde in den nächsten Tagen versuchen über ein Powershell-Script beim Start des ersten Clients das Frontend zu starten und beim Ausschalten des letzten Clients das Frontend wieder zu beeenden. (Sowas Ähnliches hatte ich auf dem alten DVBViewer Server laufen, weil die Netzwerkkarte kurz deaktiviert werden mußte, um den Server in den Energiesparmodus gehen zu lassen.)

 

Wenn das klappt, melde ich mich nochmal.

 

Vielen Dank für das "Schubsen" in die richtige Richtung. 

Gruß

 

Severin

[Griga]

vor 41 Minuten schrieb agio:

die Media Server-Option hält den Server wach und daher kommt es nicht mehr zu Problemen beim Umschalten, wenn auf einem anderen Rechner das Web-Frontend läuft.

 

Auch, wenn es etwas anderes als die alle 10 Sekunden aktualisierte Status-Seite zeigt? Ich habe da Zweifel.

 

Im Grunde lässt sich das Problem im Media Server einfach lösen. Er muss nur, wenn er Windows 11 erkennt, jedes Beenden der Standby-Blockade um eine gewisse Zeit verzögern. Fragt sich, wie lange. Glaubt man dem letzten Post in dieser Diskussion, wären es 2 Minuten, um wieder Windows 10-Verhältnisse herzustellen. Aber ich messe das lieber selbst noch mal mit einer Stoppuhr.

 

Wenn ich die Änderungen durchgeführt habe, könnte ich eine Beta-Testversion zur Verfügung stellen. Interesse?

 

[Griga]

vor 12 Stunden schrieb Griga:

Glaubt man dem letzten Post in dieser Diskussion, wären es 2 Minuten, um wieder Windows 10-Verhältnisse herzustellen.

 

Windows 10 wartet tatsächlich 2 Minuten (gemessen habe ich 1:55 Minuten), bis es nach Aufhebung der Standby-Blockade durch den Media Server den PC in den Energiesparmodus herunterfährt - vorausgesetzt, dass die dafür in Windows konfigurierte Zeit ohne Benutzeraktivität bereits abgelaufen ist. Windows 11 wartet dagegen nicht mal eine Millisekunde, und das macht im Media Server Probleme

 

Leider lassen sich unter Windows 11 keine Windows 10-Verhältnisse herstellen, indem der Media Server die Aufhebung der Standby-Blockade um 2 Minuten verzögert. Der Unterschied ist, dass während dieser 2 Minuten auch der Anwender den PC nicht in den Energiesparmodus versetzen kann. Das Ergebnis wäre der Abwesenheitsmodus (sofern in den Energie-Einstellungen zugelassen), in dem nur Bildschirm und Sound schlafengelegt werden, aber nicht das ganze System - der Lüfter rauscht weiter. Kurz gesagt würde sich ein Windows 11-PC während der 2 Minuten Verzögerungszeit so verhalten, als würde der Media Server noch aufnehmen oder Clients mit einem Stream versorgen, auch wenn er längst fertig ist.

 

Deshalb erscheint es mir sinnvoller, unter Windows 11 nur eine kurze Verzögerung im Sekundenbereich vorzusehen. Im Prinzip würde eine Sekunde reichen, um das hier beklagte Problem bei Senderumschaltungen in einem Remote-Client zu verhindern (nämlich dass der Server PC aufgrund der dabei entstehenden minimalen Lücke bei der Standby-Blockade in den Energiesparmodus herunterfährt). Und auch das hier beschriebene Problem beim automatischen Herunterfahren nach einer Aufnahme. Sagen wir mal, mit etwas Zugabe insgesamt 5 Sekunden.  Die Praxis müsste dann zeigen, ob das so brauchbar ist.

 

Letztendlich muss man damit leben, dass sich Windows 11 nach Aufhebung der Standby-Blockade durch den Media Server viel schneller in den Energiesparmodus abmeldet als vorherige Windows-Versionen. Ist halt so...

 

Gibt es Meinungen dazu? Wie gesagt könnte ich Windows 11-Geschädigten eine Media Server-Testversion mit verzögerter Aufhebung der Standby-Blockade zur Verfügung stellen.

 

[agio]

Hallo Griga,

vor 13 Stunden schrieb Griga:

Auch, wenn es etwas anderes als die alle 10 Sekunden aktualisierte Status-Seite zeigt? Ich habe da Zweifel.

Ich habe es tatsächlich nur mit der Status-Seite probiert und da hat es funktioniert.

 

vor 13 Stunden schrieb Griga:

Wenn ich die Änderungen durchgeführt habe, könnte ich eine Beta-Testversion zur Verfügung stellen. Interesse?

Oh ja, sehr gerne.

 

Gruß

Severin

 

[Griga]

vor 26 Minuten schrieb agio:

Ich habe es tatsächlich nur mit der Status-Seite probiert und da hat es funktioniert.

 

Nach Remote-Webinterface-Zugriffen blockiert der Media Server für 30 Sekunden ein Herunterfahren in den Energiesparmodus. Da die Statusseite alle 10 Sekunden aktualisiert wird, bleibt er permanent blockiert. Bei anderen Seiten wäre nach 30 Sekunden Feierabend, sofern der Browser in der Zeit nicht irgendwas abruft. Ob 30 Sekunden ausreichend sind, müsste man im Hinblick auf Windows 11 ebenfalls neu überdenken.

 

vor 26 Minuten schrieb agio:

Oh ja, sehr gerne.

 

Ich melde es hier, sobald ich die Testversion hochgeladen habe.

 

[Ratchet]

Ob nun 5 oder 10s macht doch keinen wesentlichen Unterschied, es sitzt ja dann eh niemand am PC. Außerdem haben wahrscheinlich sowieso alle Nutzer eine größere Nachlaufzeit für die Aufnahme in Verwendung, sodass die paar Sekunden im Rauschen untergehen 😀. Ich würde es nicht ganz so knäpplich bemessen. Bei Windows 10 würde es ja noch viel länger dauern.

 

Ich würde die Testversion gerne auch ausprobieren, muss nur erst wieder rausfinden, welche der vielen Energieoptionen ich wieder anknipsen muss. Ich vermute, es war die Zeitvorgabe bis Standby.

[Griga]

@Ratchet, @agio:

 

Eine Beta-Testversion des Media Servers ist jetzt erhältlich:

 

https://www.dvbviewer.tv/forum/topic/64629-dvbviewer-media-server-3000/?do=findComment&comment=514216

 

[agio]

Hallo Griga,

 

ich habe die Beta-Testversion installiert und das Problem mit dem Stromsparmodus des Servers beim Umschalten ist bei uns scheinbar erledigt. Es klappt alles, wie es soll.

 

Vielen Dank dür deinen außergewöhnlich guten Support und die schnelle Lösung.

 

Gruß

Severin

[botti 56]

Am 23.2.2024 um 12:01 schrieb Griga:

Here we go:

https://www.DVBViewer.tv/forum/topic/64628-DVBViewer-media-server-3000/?do=findComment&comment=514215

 

Hinweis zur Installation der Beta: Nur den Media Server stoppen über die Taskleiste hat bei mir nicht gereicht, um alle zu ersetzenden Dateien freizugeben.

Ich musste auch noch das Tray-Kontrollprogramm beenden, um die DVBVCtrl.exe ersetzen zu können.

Nach Neustart ist alles wieder paletti.

Edited February 24 by botti 56

[Griga]

vor 3 Stunden schrieb botti 56:

Ich musste auch noch das Tray-Kontrollprogramm beenden, um die DVBVCtrl.exe ersetzen zu können.

 

Stimmt. Ich habe entsprechende Hinweise in der deutschen und englischen Beta-Ankündigung ergänzt. Und deine Anmerkung hierhin verschoben, weil du in einem englischen Thema auf Deutsch gepostet hast.

 

@agio: Danke für den Test!

 

[Ratchet]

  

@Griga

Ich kann ebenfalls Erfolg vermelden, der erste Aufnahme-Test hat geklappt👍. Ob die 5s dauerhaft ausreichen, wird wohl erst die Zeit zeigen.

Auch von mir Vielen Dank für die Anpassung!

 

Am 24.2.2024 um 12:31 schrieb botti 56:

Ich musste auch noch das Tray-Kontrollprogramm beenden

Ja, war bei mir auch so. Überraschenderweise musste ich aber nach dem Einspielen der Dateien feststellen, dass es keinen Weg zu geben scheint, das Tray-Programm direkt wieder zu starten (zumindest gibt's kein Symbol im Startmenü dafür). Es half nur von Windows Abmelden und wieder Anmelden. Ich Nachhinein betrachtet, hätte es vermutlich wohl auch das Starten über DVBVCtrl.exe getan.

[Ratchet]

Bin vor Kurzem doch mal wieder in so einen Fall von schlafendem PC gelaufen. Da folgenden Schritte sind da vorausgegangen:

1. Aufnahme programmiert mit "Herunterfahren am Ende"
2. Aufnahme wurde gestartet
3. Kurz vor Ende der Aufnahme, eine weitere Aufnahme programmiert (per DVBViewer Controller App)
4. "Herunterfahren am Ende" vom Timer der ersten Aufnahme entfernt, während sie noch lief (per DVBViewer Controller App)
5. "Herunterfahren am Ende" für zuletzt angelegten Timer gesetzt (per DVBViewer Controller App)

Am Ende der letzten Aufnahme war der PC wieder im Standby und fuhr nach dem Wecken automatisch wieder runter (also das alte Verhalten).

Es scheint irgendwas mit diesen Änderungen der Aufnahme-Programmierung zu tun zu haben, denn ansonsten ist das Problem bisher nicht wieder aufgetaucht.

[Griga]

Um der Sache auf den Grund zu gehen, müsste ich den Ablauf im svcdebug.log sehen. Nachvollziehen kann ich es mangels Windows 11 (und Windows 11-tauglicher Hardware) nicht.

 

[Ratchet]

Ich versuche das Szenario nochmal nachzustellen. Muss ich bei alleiniger Verwendung des DMS (Viewer lief nicht) den Debug-Modus irgendwie extra einschalten (wenn ja wie)? In der Anleitung steht nur was vom DVBViewer (Debug-Modus). Wenn die nachträgliche Erfassung auch so noch geht, dann hätte ich zwar das Log, aber an den genauen Tag und die Zeit kann ich mich leider nicht mehr genau erinnern. Falls das nicht notwendig ist und das Log ein paar Tage zurück reicht, könnte ich die support.zip einfach so erstellen.

 

EDIT: Ich sehe gerade, dass es in den DMS-Einstellungen eine Checkbox "Debug-Log schreiben" gibt. Die muss vmtl. an sein, richtig?

Edited March 5 by Ratchet

[Griga]

vor 3 Minuten schrieb Ratchet:

Muss ich bei alleiniger Verwendung des DMS (Viewer lief nicht) den Debug-Modus irgendwie extra einschalten (wenn ja wie)?

 

Der ist standardmäßig eingeschaltet (DMS-Optionen -> Allgemein -> Debug-Log schreiben). Wenn du es übersichtlich machen willst, entfernst du vor der Reproduktion bei gestopptem DMS das bisherige svcdebug.log.

 

Ich überlege gerade, ob die Option Allgemein -> Warnzeit vor dem Beenden etwas mit dem Effekt zu tun hat. Der DMS veranstaltet ja einen Countdown, bevor er das Herunterfahren tatsächlich durchführt, damit der Anwender es noch verhindern kann, und währenddessen ist "Energie sparen" womöglich nicht mehr blockiert, so dass Windows 11 Gelegenheit hat, zuzuschlagen. Das werde ich morgen überprüfen.

 

vor 4 Minuten schrieb Ratchet:

Wenn die nachträgliche Erfassung auch so noch geht, dann hätte ich zwar das Log, aber an den genauen Tag und die Zeit kann ich mich leider nicht mehr genau erinnern.

 

Die Suche nach einem bestimmten Ereignis ohne Zeitangabe in einem großen Log ist mühsam. Wenn du noch die Dateinamen der Aufnahmen / die Sender / den Titel der Sendungen weißt, lässt es sich eventuell finden.

 

[Ratchet]

vor einer Stunde schrieb Griga:

Der ist standardmäßig eingeschaltet (DMS-Optionen -> Allgemein -> Debug-Log schreiben). Wenn du es übersichtlich machen willst, entfernst du vor der Reproduktion bei gestopptem DMS das bisherige svcdebug.log.

Hmm, war bei mir aus. Hatte ich wohl mal ausgeschaltet. Aber egal, ich hab das Problem sofort reproduziert bekommen.

Interessant ist, dass der Countdown-Dialog des DMS nach dem Aufwecken und zügigem anmelden bei ca. 21s runterlief, er ist also vmtl. so bei 25-40s stehengeblieben.

 

Das Log ist noch recht übersichtlich. Das Aufnahmeende mit Nachlauf lag bei ungefähr 21:53.

 

support.zip

Edited March 5 by Ratchet

[Griga]

vor 10 Stunden schrieb Ratchet:

Das Log ist noch recht übersichtlich.

 

Die entscheidende Passage ist leicht zu finden, aber unerklärlich

 

05.03.24 21:53:00.551 TServiceMain         ReleaseReference TVCR: 0
05.03.24 21:53:00.552 SendUpdate           DVBVUPDATE TMR
05.03.24 21:53:00.553 ReleaseStandbyblock  TVCR
05.03.24 21:53:00.553 SetStandbyBlock      EvaluateShutdown

 

Zunächst sagt der Recorder in der Zentrale (TServiceMain) Bescheid, dass er fertig ist und keine Standby-Blockade mehr braucht. Das setzt die Referenzzählung für die Blockade um 1 auf 0 herab, d.h. niemand braucht sie mehr. Daraufhin sollte die Blockade mit einer Verzögerung von 5 Sekunden aufgehoben werden.

 

Als nächstes geht eine Meldung an alle DVBViewer Clients, dass sie die Timerliste aktualisieren sollen - hier ohne Belang. Kurze Zeit später erfolgt die Aufhebung der Standby-Blockade - aber nicht 5 Sekunden, sondern nur 2 Millisekunden verzögert. Dafür finde ich im Quellcode keine Erklärung. Als wäre die für die Messung verwendete Windows-Zeitzählung (der TickCount) plötzlich einige Sekunden weitergesprungen, was jedoch unwahrscheinlich ist.

 

Abschließend läutet der DMS den Shutdown-Prozess mitsamt Countdown ein und aktiviert für diese Zeitspanne wieder eine Standby-Blockade. Aber zu spät - die minimale Blockade-Lücke zwischen der zweiten und dritten Log-Zeile nutzt Windows 11 gnadenlos, um den PC in Standby runterzufahren, weil das in den Energie-Optionen konfigurierte Idle-Timeout (Zeit ohne Benutzeraktivität) abgelaufen ist.

 

Wie auch immer - ich habe bei der Überprüfung einen Fehler im Code entdeckt, mit dem die Angelegenheit keinesfalls wie beabsichtigt funktionieren kann, was deiner Erfolgsmeldung widerspricht

 

Am 25.2.2024 um 15:48 schrieb Ratchet:

Ich kann ebenfalls Erfolg vermelden, der erste Aufnahme-Test hat geklappt👍.

 

Wenn die Standby-Blockade nach Ende der Aufnahme nämlich wirklich 5 Sekunden verzögert aufgehoben würde (und nicht unerklärliche 2 Millisekunden später wie in deinem Log), würde sich folgender Ablauf ergeben:

 

05.03.24 21:53:00.551 TServiceMain         ReleaseReference TVCR: 0
05.03.24 21:53:00.552 SendUpdate           DVBVUPDATE TMR
05.03.24 21:53:00.553 SetStandbyBlock      EvaluateShutdown
05.03.24 21:53:05.552 ReleaseStandbyblock  TVCR

 

Die letzten beiden Zeilen wären vertauscht. Die Shutdown-Prozedur würde Standby blockieren, aber das Aufnahmeende würde die Blockade wegen der Verzögerung 5 Sekunden später wieder aufheben. Der Shutdown-Countdown kann so sein Ende gar nicht erreichen. Die Ursache des Problems ist hier, dass die Shutdown-Prozedur die Blockade direkt veranlasst, anstatt die Referenzzählung zu benutzen, die immer mitzählt, wieviele Instanzen die Blockade gerade brauchen - sie wird i.a. nur aufgehoben, wenn der Zähler auf 0 geht. Dieses Manko hatte ich übersehen. Keine Ahnung, warum Lars das früher so gemacht hat. Vielleicht war es einfach egal, weil es noch kein Windows 11 gab.

 

Die Frage ist nun, warum es bei dir zumindest manchmal trotzdem funktioniert. Dafür gibt es mögliche Erklärungen. Vielleicht ist das Windows Idle-Timeout nicht abgelaufen. Eine kleine Erschütterung, die die Maus einen Millimeter bewegt, kann reichen, um Windows Benutzeraktivität vorzutäuschen. Oder ein anderer Client blockiert im entscheidenden Moment Standby, zum Beispiel ein UPnP-Gerät in deinem Netzwerk mit irgendeiner Anfrage - sowas kommt in deinem Log mehrfach vor (und dabei hat die 5-Sekunden-Verzögerung übrigens wie beabsichtigt stattgefunden, siehe 20:45:52.908). Dass erst der hier beschriebenen Ablauf wie von dir vermutet ein vorzeitiges Standby auslöst, sehe ich im Code nicht.

 

Sofern sich nicht weitere Erkenntnisse einstellen, kann ich jetzt nur den erkannten Fehler beheben, d.h. die fehlende Referenzzählung beim Blockieren von Standby durch die Shutdown-Prozedur ergänzen.

 

Und du kannst derweilen ein anderes Problem beheben, das mehrfach in deinem Log auftaucht, aber wahrscheinlich nichts mit Standby zu tun hat: Zumindest eine deiner Multimedia-Datenbanken ist defekt und führt immer wieder zu Ausnahmefehlern. Lösche bei gestopptem DMS im Konfigurationsordner\Database die Dateien svcmediaVideo.db3, svcmediaAudio.db3, svcmediaPhoto.db3. Sie werden automatisch neu erstellt. Gleiches gilt für die Logos.db3.

 

[Ratchet]

vor 10 Stunden schrieb Griga:

Vielleicht ist das Windows Idle-Timeout nicht abgelaufen. ... ein anderer Client blockiert im entscheidenden Moment Standby, zum Beispiel ein UPnP-Gerät in deinem Netzwerk mit irgendeiner Anfrage

Ja, beides ist denkbar, wobei der Idle-Timout zumindest nicht durch Anwesenheit verlängert worden sein sollte. Aber Windows könnte natürlich auch irgendein Update (z.B. den Defender) im Hintergrund installiert haben. Die Maus können wir vmtl. ausschließen, da der PC zum Zeitpunkt der Aufnahmen in einem anderen, zu der Zeit nicht genutzten, Raum stand. UPnP ist durchaus denkbar, denn ich habe einige UPnP-Clients/Renderer (Tablet, Handy, ShieldTV, AVR, NAS mit Headless-Kodi ohne PVR-Addon) und 2 DLNA-Server (auf dem NAS), und die können durchaus mit dem DMS-UPnP-Server auf dem PC interagiert haben (ein anderer UPnP-Server läuft auf dem PC nicht). Auf dem Tablet und Handy ist noch die DVBViewer-Controller App drauf, aber die kommuniziert wohl nur, wenn sie auch genutzt wird (nicht im Hintergrund).

 

Die bisherigen Aufnahmen mit korrektem Shutdown hatten keine nachträgliche Änderung der Timer-Einstellungen hinsichtlich "Shutdown am Ende". Das ist zumindest der einzige Unterschied, der mir in Erinnerung ist. Ich hatte deshalb vermutet, dass es evtl. eine an diesen Einstellungsänderungsverlauf (Shutdown an/aus/an) gekoppelte Verquickung mit den 5s gibt. Da die 5s ja eigentlich nur für "Shutdown an" benötigt werden, werden sie ja vmtl. durch die Timer-Umprogrammierung des Flags auf AUS wieder "entfernt" und danach durch den neuen Timer auf AN wieder "hinzugefügt" werden. Aber das war halt nur 'ne Vermutung.

 

Ich kann ja nochmal ein Szenario ohne nachträgliche Timer-Änderung (1 Timer mit Shutdown AN) ausprobieren.

 

vor 10 Stunden schrieb Griga:

Zumindest eine deiner Multimedia-Datenbanken ist defekt und führt immer wieder zu Ausnahmefehlern

Danke! Die Anzeigen haben sich in der Tat in letzter Zeit merkwürdig verhalten.

[Ratchet]

vor 2 Stunden schrieb Ratchet:

Ich kann ja nochmal ein Szenario ohne nachträgliche Timer-Änderung (1 Timer mit Shutdown AN) ausprobieren.

Diesmal gleiches Ergebnis: Standby vor Shutdown

Hab wohl die paar Male davor einfach immer Glück gehabt.

 

Neues Log: Aufnahme endete 23:08

support.zip

[Griga]

vor 17 Stunden schrieb Ratchet:

Diesmal gleiches Ergebnis: Standby vor Shutdown

 

Danke! Das gleiche Bild im Log: Der DMS hebt nach Ende der Aufnahme die Standby-Blockade schon in wenigen Millisekunden auf, nicht wie vorgesehen um 5 Sekunden verzögert. Der Wahnsinn hat also Methode

 

Ich konnte es hier sogar nach Aktivierung der Verzögerung für Windows 10 nachvollziehen. Zwar erhalte ich so kein vorzeitiges Standby wie unter Windows 11, konnte aber im Log sehen, dass die Verzögerung speziell nach Aufnahmen nicht wie geplant funktioniert (ansonsten schon). Schließlich habe ich auch die Ursache gefunden. Ich hatte nicht ausreichend berücksichtigt, dass das Beenden von Aufnahmen ebenfalls auf der Zeitmessung beruht, die für die Verzögerung zum Einsatz kommt - hier passierte schlicht etwas in der falschen Reihenfolge.

 

Am kommenden Wochenende werde ich eine korrigierte Beta-Version hochladen, sobald ich dazu komme, und es hier melden.

 

[Griga]

Ein Test unter Windows 10 mit aktivierter Verzögerung des Standby-Entblockierens zeigt jetzt nach einer Aufnahme mit "Herunterfahren" als abschließender Aktion folgenden Ablauf im svcdebug.log:

 

08.03.24 09:04:01.210 TServiceMain         ReleaseReference TVCR: 0
08.03.24 09:04:01.210 SendUpdate           DVBVUPDATE TMR
08.03.24 09:04:01.210 TServiceMain         AddReference     EvaluateShutdown: 1
08.03.24 09:04:01.210 SetStandbyBlock      EvaluateShutdown
08.03.24 09:04:01.210 SendUpdate           DVBVUPDATE PWR MEDION-PC
08.03.24 09:04:01.210 SendUpdate           DVBVUPDATE RST -871
08.03.24 09:04:25.613 TServiceMain         ReleaseReference DoShutDown canceled: 0
08.03.24 09:04:30.759 ReleaseStandbyblock  DoShutDown canceled

 

Die Aufnahme ist zu Ende, die Referenzzählung wird um 1 vermindert (ReleaseReference) und erreicht 0. Fünf Sekunden später soll nun Standby entblockiert werden. Dazu kommt es jedoch nicht, weil das Shutdown-Handling einsetzt (EvaluateShutdown) und die Referenzzählung gleich wieder hochsetzt (AddReference), damit der Countdown ungestört stattfinden kann. Diesen habe ich jedoch abgebrochen  (DoShutdown canceled), was die Referenzzählung wieder auf 0 setzt und wie beabsichtigt 5 Sekunden später die Standby-Blockade entfernt. Soweit ok.

 

DVBVUPDATE PWR ist ein Multicast-Rundruf an alle assoziierten DVBViewer-Clients, der ihnen mitteilt, dass der Server seinen PC in x Sekunden runterfährt. Das gleiche passiert, wenn die abschließende Aktion einer Aufnahme "Energie sparen" oder "Ruhemodus" ist. Die Clients zeigen dann einen Warndialog, der es ermöglicht, den Vorgang über das DMS-API abzubrechen.

 

Tja, und was macht Windows 11 dann womöglich 5 Sekunden, nachdem ein Anwender in einem Remote-Client den Abbruch veranlasst hat, weil er kein Herunterfahren möchte? Fährt den Server-PC trotzdem in den Energiesparmodus runter, weil ja die Standby-Blockade aufgehoben ist. Sehr unschön Das betrifft wohlgemerkt nur Remote-Clients, die den Server PC nicht sonstwie wachhalten. Wird der Vorgang dagegen auf dem Server-PC abgebrochen, findet dort ja eine Benutzerinteraktion statt, die den Idle-Timeout von Windows zurücksetzt.

 

Wie kann man das regeln? Wie kann der DMS den Idle-Timeout von Windows 11 programmgesteuert zurücksetzen, um es stellvetretend für einen Remote-Client zu machen? Vor dem Problem stehen auch andere Programmierer. Wirklich toll, was Microsoft sich da wieder ausgedacht hat

 

[Griga]

Es gibt jetzt eine neue Beta-Version 3.2.5.2 des Media Servers mit oben angegebenen Fixes:

 

https://www.dvbviewer.tv/forum/topic/64629-dvbviewer-media-server-3000/?do=findComment&comment=514819

[Ratchet]

Die ersten beiden Aufnahmen sind erfolgreich verlaufen, d.h. der PC ist nach den Aufnahmen korrekt heruntergefahren . Werde es weiter beobachten.

[Ratchet]

Kurze Rückmeldung zur Beta-Version:

Nach etlichen Aufnahmen kann ich vermelden, dass sowohl Shutdown als auch Ruhezustand (die beiden Varianten nutze ich) bei mir nun ohne Auffälligkeiten funktionieren.