Timers.xml und Timers.bak nach Windows-Absturz beide leer! (DVBViewer Pro)

[Webturtle]

Hallo,

 

nach einem Windows-Absturz mit Bluescreen ':(' und Neustart war die Aufnahme-Programmierung komplett leer! Als ich im Konfigurationsverzeichnis nachgesehen habe, mußte ich feststellen, daß dasselbe für die Sicherungskopie Timers.bak galt.

 

Sowohl Timers.xml als auch Timers.bak müssen schon vor dem Neustart leer gewesen sein. Ich lasse nämlich beide beim Start von Window automtisch kopieren, seit einmal bei einem fehlerhaften Start des DVBViewers Pro die Sicherungskopie durch die fehlerhafte Timers.xml ersetzt worden ist.

 

Eigentlich sollte eine Sicherungskopie doch vor einem Verlust der gesicherten Datei schützen. Daß beim selben Ereignis beide flöten gehen widersprichet diesem Gedanken.

 

Der Verlust hielt sich zum Glück in Grenzen, da ich auf die am Morgen automatisch kopierten Versionen zurückgreifen konnte und nur die im Laufe des Tages erfolgten Timer-Programmierungen nochmals vornehmen mußte und die Timer für den laufenden Tag gesichert waren.

 

 

Viele Grüße

 

Webturtle

 

[Griga]

Die Problematik dürfte ähnlich sein wie hier und ähnliche Maßnahmen erfordern.

 

[Webturtle]

Hallo,

 

ein solches Ereignis kommt zum Glück ja nicht ständig vor.

 

Ich hatte nur gedacht, daß es helfen würde, wenn der DVBViewer vor einer Änderung der Timers.bak diese z.B. in Timers.ba$ kopieren würde. Diese wäre dann sicher auf der Platte, während an der Timers.bak gearbeitet wird. Bei der nächsten Änderung könnte die Timers.bak wieder über die Timers.ba$ kopiert und die Timers.bak akktualisiert werden.

 

Mit den 3 Dateien Timers.xml, Timers.bak und Timers.ba$ (der Sicherung der Sicherung) verhält es sich in etwa wie beim Kletter mit der Drei-Punkt-Regel ( https://de.wikipedia.org/wiki/Drei-Punkt-Regel  ). Danach hat man an drei Punkten (Hände oder Füße) einen stabilen, festen Kontakt mit dem Untergrund und sucht nur mit dem vierten eine neue Position.

 

 

Viele Grüße

 

Webturtle

 

Edited February 9, 2023 by Webturtle

[Griga]

vor 11 Stunden schrieb Webturtle:

Ich hatte nur gedacht, daß es helfen würde, wenn der DVBViewer vor einer Änderung der Timers.bak diese z.B. in Timers.ba$ kopieren würde. Diese wäre dann sicher auf der Platte, während an der Timers.bak gearbeitet wird.

 

An der timers.bak wird nicht gearbeitet. Die Datei entsteht durch Umbenennen der timers.xml.

 

Die (wahrscheinlich) erforderlichen Maßnahmen sind dem oben von mir angegebenen Thema zu entnehmen. Ich werde die Diskussion hier nicht noch mal auf Deutsch wiederholen. Zwar habe ich den Umgang mit der timers.xml im DVBViewer noch nicht genau untersucht, aber er dürfte ähnlich wie im Media Server sein.

 

[Webturtle]

Hallo Griga,

 

nur zur  Ergänzung: Zur Zeit des Ereignisses lief auch der GE mit einem eigenen DVB-T2 HD Stick für unsere Hausantenne. Dessen Timer-Programmierungen waren im Gegensatz zum Pro nicht betroffen.

 

Wegen des von Dir geschilderten Problems ( https://www.DVBViewer.tv/forum/topic/67797-svctimersxml-after-bsod-empty/?do=findComment&comment=507993  ) wenn mit einer leeren Timers.xml gestartet wird und die Timers.bak durch die leere Timers.xml überschrieben wird, wenn man das Programm wieder beendet z.B. wenn es nicht richtig funktioniert, habe ich ja mithilfe von AutoHotkey eine Batchdatei geschrieben. Diese kopiert die Timers.xml und Timers.bak in ein Unterverzeichnis und hängt dabei Datum und Uhrzeit an den Dateinamen, um ein Überschreiben vorhandener Dateien zu verhindern.

 

Im geschilderten Fall enthielten beide Dateien beim Rechnerstart keine Timer mehr. Die Timers.xml hatte die Größe 111 Byte und bestand nur aus einem Header. Die Timers.bak hatte eine Größe von über 80.000 Byte und bestand nur aus 00h.

 

Viele Grüße

 

Webturtle

 

P.S. @Griga: Ich werde mir den von Dir verlinkten englischsprachigen Thread noch mal in Ruhe durchlesen. Gestern war es mir dafür echt zu spät.

 

Edited February 10, 2023 by Webturtle

[Griga]

vor 12 Stunden schrieb Webturtle:

Im geschilderten Fall enthielten beide Dateien beim Rechnerstart keine Timer mehr. Die Timers.xml hatte die Größe 111 Byte und bestand nur aus einem Header. Die Timers.bak hatte eine Größe von über 80.000 Byte und bestand nur aus 00h.

 

Dieses Ergebnis erhälst du z.B. bei folgendem Ablauf:

• Eine Aufnahme wird beendet. Der DVBViewer will eine neue timers.xml erzeugen und benennt zunächst die vorherige in timers.bak um, bevor er die neue timers.xml schreibt.
• Bei der Freigabe des DVB-Gerätes stürzt der instabile Treiber ab -> BSOD. Windows kommt nicht mehr dazu, den Schreibcache wegzuschreiben. Die neue timers.xml bleibt leer (0 Bytes).
• Nach dem PC-Neustart gibt es eine leere timers.xml und eine intakte timers.bak.
• Beim Start liest der DVBViewer die defekte timers.xml. Das Ergebnis ist eine leere Timerliste. Diese schreibt er sofort wieder raus (wodurch eine timers.xml nur mit Header entsteht), löscht zuvor die timers.bak und benennt die defekte timers.xml in timers.bak um.

Problem Nummer 1 ist dabei, dass du zumindest ein DVB-Gerät mit instabilem Treiber verwendest.

 

Problem Nummer 2 ist, dass du den DVBViewer nach dem BSOD startest. Voher könntest du noch per Hand die timers.xml durch die timers.bak ersetzen.

 

Problem Nummer 3 ist, dass der DVBViewer beim Start mit der timers.bak alles andere als sinnvoll umgeht. Wenn er merkt, dass die timers.xml ungültig bzw. beschädigt ist, sollte er sie nicht zur neuen timers.bak machen, sondern automatisch die alte timers.bak laden, so dass dies nicht der Anwender per Hand in die Wege leiten muss. Das werde ich jetzt entsprechend ändern.

 

[Webturtle]

Hallo Griga,

 

vielen Dank für die ausführlichen Erläuterungen.

 

es stimmt, daß ich den DVBViewer automatisch nach dem Booten starten lasse. Bei 'normalen' Abstürzen hat das den Vorteil, daß der DVBViewer die begonnenen Aufnahmen wenigstens fortsetzt - mit Glück fällt der Absturz in eine Werbeunterbrechung - und spätere Timer noch ausführt.

 

Zu 1): Ich benutze seit Jahren zwei DVBSky S-960 und zwei Astrometa DVB-T2 HD Sticks. Probleme mit den Treiber habe ich bisher eigentlich nicht bemerkt.

 

Zu 2) und 3): Die geschilderte Problematik ist mir aus früherer Erfahrung bewußt. Da ich die beim Neustart vorhandenen Timers.xml und Timers.bak automatisch vor dem Start des DVBViewers ins Sik-Verzeichnist kopieren lasse, kann der DVBViewer diese Kopien nicht mehr kompromitieren. Der DVBViewer wird mit einer gewissen Zeitverzögerung gestartet, damit die Hardware bereits initialisiert ist. Bevor er gestartet wird, bekomme ich vom AutoHotkey-Script - es ist in Wirklichkeit gar keine Batchdatei - in einem Message-Fenster angezeigt, daß die Timer-Dateien gesichert sind.

 

 

Viele Grüße

 

Webturtle

Edited February 11, 2023 by Webturtle

[Griga]

Am 11.2.2023 um 14:38 schrieb Webturtle:

Probleme mit den Treiber habe ich bisher eigentlich nicht bemerkt.

 

BSODs werden i.a. durch Treiber (oder allgemeiner: Kernel-Module) ausgelöst, nicht durch Anwendungen. Sinn des BSOD ist es, System, Daten und Hardware vor Schäden zu schützen, die  unkontrollierte Abläufe verursachen könnten, und auch anzuzeigen, welches Modul mit welchem Fehler den Nothalt ausgelöst hat. Letzteres muss man allerdings erst konfigurieren: Systemsteuerung -> System ->  Erweiterte Systemeinstellungen -> Starten und Wiederherstellen -> Einstellungen -> Erweitert -> Systemfehler -> Automatisch Neustart ausführen aus. Eventuell lohnt es sich auch, in der Windows-Ereignisanzeige nach kritischen Fehlern Ausschau zu halten.

 

Wie auch immer: Ich stelle dir per PM eine DVBViewer-Testversion zur Verfügung, die die timers.xml nun entsprechend diesen Änderungen im Media Server handhabt. Der Änderungsverlauf für den DVBViewer sieht damit konkret so aus:

• Change: Recorder: Different handling of loading/saving the timer list from/to the file timers.xml:

  • The timer list is not saved anymore right after loading the timers.xml on DVBViewer start (needless though obsolete list entries may be dropped on loading).

  • The timer list is not saved anymore right before the PC enters sleep mode / hibernate (needless if all timer list changes have been saved before, which should usually be the case). Please note that the list is still saved on closing DVBViewer, though also needless. It is done “just in case” to make sure that the current state of the timer list is identical with the version on disk. Usually, if all changes have already been saved before, this measure will yield identical timers.xml and timers.bak files.

  • If the file timers.xml is detected as corrupted on loading (not empty, but incomplete or XML syntax errors), it is renamed to timers[yyyymmddhhnnss].bak, where [yyyymmddhhnnss] is the current date and time, yielding something like timers20230105100634.bak. This measure ensures that the corrupted file cannot become timers.bak. The renamed file can be used for manual repair attempts. If DVBViewer is running in debug mode, this event is logged in the file DVBViewer.log.

  • If the file timers.xml is detected as invalid on loading (0 bytes or no “settings” root node), it is deleted, so it cannot become timers.bak. This event is now logged in the file svcdebug.log.

  • If the file timers.xml can not be loaded, because it is corrupted or empty/invalid, the file timers.bak (which contains the previous timer list state before the latest change was saved) is renamed to timers.xml and loaded. If DVBViewer is running in debug mode, this event is logged in the file DVBViewer.log.

 

 

 

[Webturtle]

Hallo Griga,

 

vlelen herzlichen Dank! Das klingt sehr vernünftig.

 

Ich werde die Testversion gerne ausprobieren und hoffentlich nicht wirklich testen müssen 😉 . Außerdem werde ich mal die Systemeinstellungen wie vorgeschlagen vornehmen.

 

Ohn unbescheiden wirken zu wollen, möchte ich bei der Gelegenheit noch mal anregen, ob nicht auch eine sicherere Lösung für die EPG.dat möglich wäre. Und zwar in der Hinsicht, daß die neu geladenen EPG-Daten gleich und nicht erst beim Beenden des DVBViewers in der EPG.dat gespeichert werden. Ich habe es schon öfters erlebt, daß der DVBViewer hängengeblieben ist und die ganzen neu geladenen EPG-Daten perdu waren. Und das Schlimmste war, daß man wegen einer nun laufenden Aufnahme nur sehr begrenzt EPG-Daten neu laden konnte. Vgl. auch https://www.DVBViewer.tv/forum/topic/67935-epg-data-lost-after-bsod/

 

Eine Sicherung gegen Verlust wie bei den Timer-Dateien wäre nicht unbedingt erforderlich, da der Verlust der neu geladenen Daten nicht so dramatisch ist wie bei den Timern.

 

Ob dies durch ein automatisches Aktualiesieren der EPG.dat oder durch einen Befehl im Menü realisiert würde, wäre gleichermaßen hilfreich.

 

 

Viele Grüße

 

Webturtle

 

Edited February 13, 2023 by Webturtle

[Webturtle]

Hallo Griga,,

 

ich habe es mal mit den zwei Timer-Dateien, die nach dem "Ereignis" im Sik-Verzeichnis standen, getestet.

 

(1) Timers.xml, Länge 111 Byte:

 

<?xml version="1.0" encoding="utf-8"?>
  <settings>
    <section name="VCR"/>
    <Timers/>
  </settings>

 

(2) Timers.bak, Länge: 88.402:

 

Bestehend nur aus hexadezimal NULL (00h).

 

Wenn Nummer (2) Timers.xml war hat alles wie geplant funktioniert. Es wurde aus Timers.xml timers20230213232430.bak und dann aus der Timers.bak eine Timers.xml. Eine Timers.bak erschien erst später nach dem Schließen des DVBViewers. Wahrscheinlich wäre sie auch zum Zeitpunkt eines Timerereignisses, z.B. Programmierung eines neuen Timers oder Timeraufnahme, erstellt worden.

 

Wenn aber Nummer (1) die Timers.xml war, und das war sie nach dem "Ereignis" beim Rechnerneustart vor dem Start des DVBViewers, wurde die Timers.bak, in der sich zwei Timer befanden, durch die leere Timers.xml mit lediglich dem Header ersetzt..

 

 

Viele Grüße

 

Webturtle

 

[Griga]

Danke für die Rückmeldung. Die Ergebnisse entsprechen in beiden Fällen den erwarteten Resultaten.

 

Der zweite geschilderte Fall wird in der Praxis nicht mehr auftreten, da wie im Änderungsverlauf angegeben eine beschädigte timers.xml nicht mehr zur timers.bak werden kann.

 

[Webturtle]

Hallo Griga,

 

dann will ich mal hoffen, daß der DVBViewer nicht beim Absturz eine vorschriftsmäßige leere Timers.xml mit Header produziert. Das war wohl ein eher ungwöhnlicher Fall

 

Es ist jedenfalls beruhigend, daß der DVBViewer auch nach einem Absturz weiter die geplanten Sendungen aufnehmen kann.

 

Vielen Dank für Dein schnelles Tätigwerden!

 

 

Viele Grüße

 

Webturtle

 

[Griga]

vor 23 Stunden schrieb Webturtle:

dann will ich mal hoffen, daß der DVBViewer nicht beim Absturz eine vorschriftsmäßige leere Timers.xml mit Header produziert.

 

Kaum möglich. Durch einen Absturz betroffene Schreiboperation ergeben entweder eine unvollständige Datei oder eine ohne Text. Beides erkennt der DVBViewer als ungültig. Eine leere timers.xml mit Header entsteht, wenn der DVBViewer eine leere Timerliste regulär speichert (siehe hier).

 

In der Testversion gibt es noch einen kleinen Fehler - gerade entdeckt und korrigiert. Das Handling der timers.xml setzt voraus, dass der DVBViewer nach jeder Änderung der Timerliste sofort eine neue timers.xml schreibt, so dass die Timerlisten im Speicher und auf Festplatte konsistent bleiben. Nach "Übernehmen" im Aufnahmeprogrammierung-Fenster schreibt der DVBViewer zwar auf jeden Fall eine neue timers.xml. Ein in dem Fenster geänderter Aufnahmeordner erfordert jedoch kein "Übernehmen", um wirksam zu werden, was ich übersehen habe.

 

Work Around: Auch nach Ändern des Ordners auf "Übernehmen" klicken, obwohl eigentlich unnötig.