Searches.xml enthält nur Nullen (0x00)

[DetlefM]

Ich habe heute die Version 3.2.4 (vorher 3.2.1) aufgespielt und hoffe, dass ein Bug der die searches.xml zerschießt nicht mehr auftritt. In den Releasenotes habe ich nichts gefunden - trotzdem vorsichtshalber mal die neueste Version.

Mein Aufnahme PC läuft mit Windows 10 und natürlich kommt ab und zu mal Windows auf die Idee Patches herunterzuladen. Jedenfalls habe ich den Windows Update Prozess in Verdacht. Beweisen kann ich es aber nicht. Jedenfalls: Ab und zu ist danach die searches.xml kaputt. Sie hat dann die gleiche Größe aber statt xml Text als alles Binäre Nullen (bei mir halt 41K).

Nach meinen Erkenntnissen wird die Searches.xml Datei bei jedem Beenden des Mediaservers geschrieben - ob sich nun der Inhalt geändert hat oder nicht. Und meine Vermutung geht dahin, dass bei einem Windows Update (kann natürlich auch was anderes sein) dieses Schreiben zu dem Nullen führt.

Jedenfalls war jeweils beim Auftreten (bislang 2x bei mir in den letzten Monaten) der Edge Explorer erneuert worden und ich musste mich per Remote neu anmelden.

Ich denke über den Update auf W11 nach - hat jemand dazu eine Meinung oder Erfahrung?

 

[Griga]

16 hours ago, DetlefM said:

Ab und zu ist danach die searches.xml kaputt. Sie hat dann die gleiche Größe aber statt xml Text als alles Binäre Nullen

 

Sowas passiert eigentlich nur bei Abstürzen, oder wenn ein Programm im ungeeigneten Moment gewaltsam beendet wird. Es kann auch Windows-intern schiefgehen, da bei stationären (nicht entfernbaren) Laufwerken meistens ein Schreibcache aktiv ist. Was ein Programm wegschreibt, landet also nicht sofort auf dem Laufwerk, sondern verzögert.

 

Ein Backup-Mechanismus wie der letztlich renovierte für die svctimers.xml könnte solche Probleme zumindest mildern. Warum der ursprüngliche DMS-Entwickler (Lars) keinen für die searches.xml vorgesehen hat, weiß ich nicht. Ich schaue bei Gelegenheit mal, ob sich das Verfahren übertragen lässt.

 

[DetlefM]

Bei mir läuft der Server 7x24 und wird per Hand praktisch niemals direkt ausgeschaltet. Eine gewaltsame Beendigung kann ich aber nicht komplett ausschließen es kann ja durchaus vorkommen, dass der Strom ausfällt und dann, wenn der Strom wieder fließt, der Rechner von allein wieder hochfährt (habe ich im Bios so eingestellt). Nur dürfte in diesem Fall eigentlich nichts passieren. Wenn Strom weg dann können auch keine fehlerhaften Buffer geschrieben werden. Wenn das Update von Windows einen Neustart macht, dann werden ja alle Prozesse informiert - also hier sollte der Mediaserver auch fehlerfrei agieren können. Er bekommt noch etwas Zeit zum Reagieren.

Mal sehen ob ich einen Weg finde die unterschiedlichen Bootvorgänge zu unterscheiden und ein Log über die Bootvorgänge anzulegen (oder macht das Windows schon irgendwo und ich weiß es nur nicht?).

Ich hätte gedacht, dass es unnötig ist beim Herunterfahren des Mediaservers diese Dateien zu schreiben. Für die Aktualisierung der Timer und so braucht er eigentlich nur Lesezugriff und schreiben sollte er nur wenn eine Änderung an den Dateiinhalten notwendig ist - und dann eigentlich sofort. Sei es durch die Oberfläche oder über die API. Aber egal, der Entwickler wird sich schon einen Grund gehabt haben.

Ich denke jetzt über eine tägliche Sicherung und Überprüfung mit dem Sollzustand der Dateien nach. Da der Rechner unbeobachtet auch im Urlaub aufnehmen soll ist eine fehlerhafte Konfigurationsdatei Gift für den Prozess.

Interessant war jedenfalls, dass der Mediaserver ohne Mucken die Datei mit vielen, vielen Nullen einfach so schluckt und nicht murrt - oder gibt es dafür eine Logdatei?

[Griga]

2 hours ago, DetlefM said:

Wenn Strom weg dann können auch keine fehlerhaften Buffer geschrieben werden.

 

Das Erzeugen einer Datei umfasst verschiedene Phasen. Je nach dem, zu welchem Zeitpunkt der Strom ausfällt und ein Absturz geschieht, kann alles mögliche passieren. Die Nullen stammen jedenfalls nicht vom Media Server. Womöglich wurde die Datei vorbereitet, mitsamt Einträgen im Dateisystem, aber nicht mehr mit Inhalt gefüllt.

 

2 hours ago, DetlefM said:

Wenn das Update von Windows einen Neustart macht, dann werden ja alle Prozesse informiert - also hier sollte der Mediaserver auch fehlerfrei agieren können. Er bekommt noch etwas Zeit zum Reagieren.

 

Er macht dann alles dicht, schließt Netzwerkverbindungen, schreibt seine Konfigurationsdateien, beendet die Nutzung von DVB-Geräten usw. Wenn aber zufällig der Treiber eines DVB-Gerätes bei der Freigabe mit BSOD abstürzt... hatten wir schon alles. Daraus und aus weiteren ähnlich gelagerten Fällen resultierte die Renovierung des Backup-Mechanismus bei der (svc)timers.xml, den es zwar gab, der aber alles andere als sinnvoll arbeitete.

 

2 hours ago, DetlefM said:

schreiben sollte er nur wenn eine Änderung an den Dateiinhalten notwendig ist - und dann eigentlich sofort. Sei es durch die Oberfläche oder über die API.

 

Bei Änderungen im Webinterface macht er es, bei Änderungen über das API nicht (vorhin überprüft). Bei letzteren ist das Problem, dass eventuell viele ändernde API-Aufrufe hintereinander kommen und nach jedem die Datei neu geschrieben werden müsste. Der DMS weiß nicht, ob noch weitere Aufrufe folgen. Allerdings wird das bei Timern auch in Kauf genommen.

 

Grundsätzlich gilt: Je mehr Schreibvorgänge, um so größer die Angriffsfläche für Datenverluste durch Abstürze & Co. Wirklich Sinn macht als Gegenmittel nur ein Backup-Mechanismus, und der fehlt hier halt.

 

Wenn du etwas dagegen tun willst., schaltest du den Schreibcache für dein Laufwerk aus. Schreibvorgänge werden dann zwar lahmer, aber dafür steigt die Sicherheit deiner Daten, worauf Microsoft auch hinweist.

 

2 hours ago, DetlefM said:

Interessant war jedenfalls, dass der Mediaserver ohne Mucken die Datei mit vielen, vielen Nullen einfach so schluckt und nicht murrt

 

Wenn die Datei keinen gültigen XML-Inhalt hat, steigt er aus dem Vorgang kommentarlos (ohne Log-Eintrag) aus. Darüber hinaus gibt es keine Maßnahmen, die einen Fehlschlag behandeln, weder beim Lesen noch beim Schreiben der searches.xml.  Bei der svctimers.xml sieht das inzwischen wie gesagt ganz anders aus.

 

[DetlefM]

Quote

 

  7 hours ago, DetlefM said:

schreiben sollte er nur wenn eine Änderung an den Dateiinhalten notwendig ist - und dann eigentlich sofort. Sei es durch die Oberfläche oder über die API.

 

Bei Änderungen im Webinterface macht er es, bei Änderungen über das API nicht (vorhin überprüft). Bei letzteren ist das Problem, dass eventuell viele ändernde API-Aufrufe hintereinander kommen und nach jedem die Datei neu geschrieben werden müsste. Der DMS weiß nicht, ob noch weitere Aufrufe folgen. Allerdings wird das bei Timern auch in Kauf genommen.

 

Dann stellt sich die Frage, warum er überhaupt noch einmal schreibt, wenn der Mediaserver beendet wird. Bei mir wird praktisch nur alle paar Wochen mal die searches.xml per Webinterface angefasst - halt wenn ich eine Serie entferne oder eine neue hinzufüge. Was ich öfters mache, ist per API (alle paar Tage) die Timer, die zu bereits aufgenommenen Episoden gehören, zu deaktivieren. Aber selbst wenn ich per API die Searches ändern würde gäbe es ja nur 2 Möglichkeiten: Entweder der Mediaserver kann während seiner Laufzeit alle Änderungen verarbeiten und dann beim nächsten Timeout (er erwartet keine weiteren API Calls mehr) die Datei zu öffnen und die Datei komplett neu überschreiben (wieder kein Grund beim normalen Beenden was mit der Searches Datei zu tun) oder aber er kann aufgrund eines Stromausfalles zwar noch die Datei öffnen und etwas schreiben und wird dabei unterbrochen. Aber das erscheint mir doch als ein wirklich seltenes Ereignis.

Ok - ich werde für mich eine Lösung finden und danke für die Erklärungen. 

[Griga]

13 hours ago, DetlefM said:

Dann stellt sich die Frage, warum er überhaupt noch einmal schreibt, wenn der Mediaserver beendet wird.

 

Solange Änderungen via API nicht sofort weggeschrieben werden, muss er ja wohl. Davon abgesehen ist Redundanz in Grenzen nicht schlecht. Wer weiß, ob vorher alle Speichervorgänge tatsächlich wie vorgesehen stattgefunden haben? Zumindest beim Beenden sollte die Konsistenz zwischen Speicherinhalt und Datei sichergestellt werden. Deshalb werde ich das wahrscheinlich beibehalten. Eine andere Frage betrifft das Speichern vor dem Übergang in den Energiespar/Ruhemodus. Das hatte ich bei der (svc)timers.xml gestrichen.

 

Ich werde wahrscheinlich für die searches.xml den Backup-Mechanismus für die (svc)timers.xml weitgehend übernehmen, da er sich bewährt hat. Seitdem gab es jedenfalls keine Klagen mehr über "genullte" Dateien. Ob die Maßnahmen mit deiner Privatlösung verträglich sind, werden wir sehen...