TTD Forum

chris86 hat geschrieben:Ist dieser Log direkt nach dem Neustart (bei dem die HDD geprüft wurde!) gemacht worden? Wenigstens da müsste das FS doch intakt sein... Und v.a. nicht neue Dateien defekt sein...

Direkt nach dem Neustart! Ich bleibe dabei, ein fsck auf einem gemounteten Filesystem ist im r/o-Modus nicht aussagekräftig und kann im r/w-Modus die Platte völlig ruinieren. Deswegen habe ich die Logs auch als 'unspektakulär' bezeichnet.

Ich gehe davon aus, dass die Festplattenüberprüfung beim Reboot auf dem nicht-gemounteten Filesystem stattfindet. Dabei werden mögliche Fehler automatisch behoben und das Filesystem ist beim Mounten sauber. Was mein anschließender jfs_fsck -n an Meldungen bringt, ist nicht unbedingt vertrauenswürdig. Wenn ich Zeit habe, baue ich vielleicht die Festplatte aus und schaue mir die Misere mit dem "UFS Explorer" an.

chris86 hat geschrieben:Das letzte ist ein Fehlschluss! Bei deinem letzten Test mit der vorigen Version hast du auch schon berichtet, dass kein Freeze aufgetreten ist. Denke, das hat eher mit der Startreihenfolge der TAPs zu tun - oder ist ebenfalls ein sporadisches Problem...

Das habe ich anders interpretiert: Gestern liefen keine Autostart-TAPs und Timeshift war deaktiviert. Da hat mich der Nicht-Freeze kaum gewundert, auf der Platte war einfach "nichts los". Heute jedoch habe ich im "Standard-Modus", also mit TAPs und Timeshift getestet.

Gruß
Herbert

Umlaute waren seinerzeit bei mir nicht im Spiel.

[quote="Igodauge"]Eine Frage nur nebenbei, ohne etwas andeuten zu wollen. Welche Version von SE hast du im Einsatz? Ist das schon eine 6er?[/quote]
Nein. V.5.5. Das ist die aktuelle im TtD.

klassikmann hat geschrieben:Das habe ich anders interpretiert: Gestern liefen keine Autostart-TAPs und Timeshift war deaktiviert. Da hat mich der Nicht-Freeze kaum gewundert, auf der Platte war einfach "nichts los". Heute jedoch habe ich im "Standard-Modus", also mit TAPs und Timeshift getestet.

Sorry, das hab ich dann wohl falsch verstanden...
Aber ich wage trotzdem zu bezweifeln, dass ein "Schneiden" einen Freeze in einem anderen TAP verhindern kann... könnte ich mir zumindest technisch nicht erklären (obwohl es da ja noch ein paar mehr Sachen gibt, die ich nicht erklären kann^^)

klassikmann hat geschrieben:Direkt nach dem Neustart! Ich bleibe dabei, ein fsck auf einem gemounteten Filesystem ist im r/o-Modus nicht aussagekräftig und kann im r/w-Modus die Platte völlig ruinieren. Deswegen habe ich die Logs auch als 'unspektakulär' bezeichnet.

Wo du recht hast, hast du recht.
Aber Fakt ist nunmal auch, dass wir hier einem Problem mit einem inkosistenten FileSystem auf der Spur sind, welches Dateien verliert. Wenn wir also von fsck irgendwelche Meldungen bekommen, die genau darauf hinweisen, dann sollten wir denen möglichst auch nachgehen.

Nach meiner Interpretation ist es so:
Während ein Dateisystem gemountet ist, darf es gelegentliche kurzzeitige Inkonsistenzen aufweisen, da Schreiboperationen nicht atomar durchgeführt werden. z.B. werden während einer Aufnahme vermutlich permanent neue Blöcke im Voraus reserviert und vollgeschrieben - der Eintrag ins Dateisystem erfolgt dann aber erst später...
Deshalb zeigt fsck einen Fehler an (der zu dem Zeitpunkt auch tatsächlich vorhanden ist), der aber nicht kritisch ist (und keinesfalls "repariert" werden sollte), da das FS noch dabei ist, den Zustand selbst wieder richtigzustellen...
Das ist der Grund, warum fsck niemals ein gemountetes System reparieren sollte. Und warum in gemountetem Zustand manchmal "Phantom-Fehler" angezeigt werden, die kurze Zeit später wieder verschwunden sind.
Aber fsck "erfindet" auch in gemountetem Zustand nicht einfach irgendwelche Fehler, die nicht zu dem Zeitpunkt gerade vorhanden sind (wenn auch nur temporär).
Und es könnte durchaus möglich sein, dass irgendein HDD-Zugriff während eines solchen Zustands der temporären Inkonsistenz stattfindet, und somit unser allerseits gefürchtetes Phänomen verursacht.

Ich schlage also vor, dass wir (um wichtige von unwichtigen Fehlern zu unterscheiden) bei künftigen fscks folgendes tun:

• vor dem fsck möglichst alle gleichzeitigen Schreibzugriffe abschalten (insbesondere Aufnahmen und Timeshift)
• vor dem fsck einmal 'sync' aufrufen, um das FS anzuweisen, anstehende Schreiboperationen jetzt durchzuführen
• abwarten, bis das passiert (eine halbe bis ganze Sekunde sollte reichen)
• jetzt zur Sicherheit noch ein hdparm -f
• fsck mit den Parametern -n und -v aufrufen, und die (hoffentlich nur wenigen) Meldungen, die dabei entstehen, ernst nehmen

klassikmann hat geschrieben:Wenn ich Zeit habe, baue ich vielleicht die Festplatte aus und schaue mir die Misere mit dem "UFS Explorer" an.

Das wäre natürlich auch eine ziemlich coole Idee. Oder auch als externe Platte an den Topf anschließen, und dann in ungemountetem Zustand mit fsck prüfen (dafür muss die Platte nichtmal ausgebaut, sondern nur per e-SATA angeschlossen werden ;-))

Und ich werde als nächstes eine MC-Version erstellen, die nach dem Schnitt selbstständig ein fsck durchführt und das Log auf verdächtige Einträge untersucht.
Das erspart uns viel Aufwand beim künftigen Debuggen, und v.a. es ermöglicht wenigstens den Benutzer rechtzeitig zu warnen, falls seine Aufnahmen beim nächsten Start verschwinden - so dass er zuvor noch ausreichend Gelegenheit hat, sie zu sichern ;-)

[quote="Twilight"]
aus meinen berichten siehst du das ich viel geschnitten habe, ohne das datein verschwunden sind, habe eine WD platte.
[/quote]

Danke, Twilight! Dich hatte ich zwar schon auf der WD-Funktioniert-Liste... Aber magst du mir noch das genaue Modell deiner Festplatte verraten? Insbesondere wäre interessant, ob sie 'Advanved Format' (4K-Sektoren) nutzt, oder nicht...

HDDModel : WDC WD20EARS-00MVWB0

twilight

Heute ist mir auch wieder eine Aufnahme verschwunden.
Die .inf und .nav sind noch da, die .rec ist weg. MovieCutter war seit Tagen nicht gestartet,
es wurde auch nichts geschnitten. Der Topf hat die Aufnahme heut Nachmittag beendet und war dann nicht mehr bedienbar. Nach dem Neustart kam prüfe Festplatte, es wurden danach keine Taps automatisch vom Topf gestartet, warum weiß ich nicht und das ist alles sehr merkwürdig.

Die verschwundene Aufnahme wurde nie geschnitten oder ist es nur schon länger her?

[quote="db1"]Die verschwundene Aufnahme wurde nie geschnitten oder ist es nur schon länger her?[/quote]
Nein, die Sendung wurde nie geschnitten. Konnte sie auch gar nicht, da die verschwundene Sendung kurz vor dem Absturz aufgezeichnet wurde. Es war eine Aufnahme von Olympia im ZDF. Sie war über 20 GByte groß. Meine bessere Hälfte war stinke sauer ....
Zum Zeitpunkt der Aufnahme habe ich gleichzeitig Sky geschaut. Der Receiver lief ganz normal weiter, nur das Display nach Aufnahmeende war stehen geblieben. Der TMS konnte nur noch über die FB ausgeschaltet werden.

Also der reboot (und das Löschen der Aufnahme) fand statt, als die Aufnahme noch gar nicht richtig beendet war? Das hat dann aber nichts mit MC zu tun.

Nur leider hatte ich heute auch wieder einen reboot (viewtopic.php?p=990068#p990068) mit verlorenen geschnittenen filmen :-(
Übrig gebliben sind neben inf und nav auch noch *.cut.bak
Es sind aber sicher nicht alle geschnittenen Filme gelöscht worden und es sind auch *.cut.nav von Filmen übriggeblieben, die nicht verschwunden sind. Falls sie helfen sind sie wieder in:
https://www.dropbox.com/sh/2sl1nz4w0ns3cao/aybEtdrpi_

Gelöscht wurden: Batman, Jurassic Park 3, Matrix Reloaded (auf externer HD), Matrix (auf externer HD)
Nicht gelöscht: Moon, Vergessene Welt - Jurassic Park

Die Aufnahme war 20 Minuten bevor ich den Display-Freeze bemerkt hatte beendet. Der TMS stand in dem Zustand wie er normal eigentlich die PVR -Info für das Ende der Aufnahme anzeigen sollte. Warum das Display dann für einige Zeit immer stehen bleibt weiß ich nicht.
Ich glaube das er am Ende einer Aufnahme etwas in die FileDB von SmartEPG schreibt.
Das verschwinden der Aufnahmen hat meiner Meinung nach nicht direkt etwas mit MC zu tun.

Ich bewundere ja wirklich eure Geduld und Opferbereitschaft.

Ich setze nach wie vor Firebirds Version vom MC ein, weil ich nicht möchte, dass Aufnahmen wahllos verschwinden. Mit der 'alten' Version gab es nie Probleme.

In diesem Zusammenhang stellt sich mir folgende Frage:
Wenn ich das richtig verstehe (man korrigiere mich, wenn dem nicht so ist), ist MC zunächst einmal ein Frontend, mit dem vom Anwender die Schnittpunkte (jeweils von Position bis Position) erstellt werden und aus diesen wird dann in einer Art Batch die Firmware veranlasst, die Schnitte auszuführen. Letzteres ist doch bei Firebirds Version sicher genauso, nur verschwinden keine Dateien im Nirvana.

Gibt denn der Vergleich dieser Programmteile MC alt/MC neu keine Hinweise?

[quote="Roemer"]Ich setze nach wie vor Firebirds Version vom MC ein, weil ich nicht möchte, dass Aufnahmen wahllos verschwinden. Mit der 'alten' Version gab es nie Probleme.[/quote]
Bei mir ist auch mit der neuen Version noch nie eine Datei verschwunden.

Gruß, Horst

[quote="macfan"]Bei mir ist auch mit der neuen Version noch nie eine Datei verschwunden.

Gruß, Horst[/quote]

Das mag ja so sein, aber alleine die latente Gefahr hält mich davon ab, diese einzusetzen.

Roemer hat geschrieben:Ich setze nach wie vor Firebirds Version vom MC ein, weil ich nicht möchte, dass Aufnahmen wahllos verschwinden. Mit der 'alten' Version gab es nie Probleme.

Welche Version ist das nochmal

macfan hat geschrieben:Bei mir ist auch mit der neuen Version noch nie eine Datei verschwunden.

Bei mir bis heute früh auch nicht (TMS war in letzter Zeit "erschreckend" stabil).
Hattest du inzwischen schon ein "Prüfe Festplatte"?

Oft, aber nicht wegen MC.

Gruß, Horst

Roemer hat geschrieben:Gibt denn der Vergleich dieser Programmteile MC alt/MC neu keine Hinweise?

Das klingt so einfach, ist es aber natürlich nicht. Du glaubst gar nicht, wie oft bereits testweise MC direkt nach einem Schnitt mit dem Hauptschalter gestoppt wurde und trotzdem ist nichts verschwunden. Sollte die Beschädigung des Dateisystems durch einen irgendwann auftretenden Pufferüberlauf ausgelöst werden, ist ja nicht nur das komplette MC verdächtig, und da hat sich seit der V1.4 viel getan, sondern auch ein Großteil der FireBirdLib, die eine Menge Funktionen zur Verfügung stellt. Und dass praktisch nur eine Person Aufnahmen halbwegs auf Befehl verschwinden lassen kann, macht das Debuggen auch nicht einfacher.

Verstehe. Nichts ist übler, als eine Fehlersituation, die man nicht nachstellen kann. Die bekommt man im Prinzip nicht gelöst - die kann man höchstens versuchen, weiträumig zu umgehen.

Mir ist übrigens bei der letzten Aktion anscheinend auch eine Datei von RNB beschädigt worden, da nun plötzlich ältere nicht entschlüsselte Dateien wieder in den Autodescramble Folder verschoben wurden?


edit: das obige ist falsch, es war ein Irrtum meinerseits!

RbN scannt nur ein Mal und dann nie wieder. Beweise werden aber gerne entgegengenommen.