lost+found TAP

[JayTee]

Die Erklärung gabs aktuell in einem anderen Thread.

Dateien in Unterverzeichnissen behalten ihren Originalnamen, alles was direkt unter /DataFiles lag bekommt .rcn

[FireBird]

TimerDiags, von dem die Meldung kommt, führt eine eigene kleine Datenbank mit Dateiname und inoden und nimmt bei der Meldung den Namen aus der DB.

[mecir]

...danke für die Antworten.

Und gibt es einen Trick, die Umbenennungen meiner knapp 250 Dateien zu automatisieren?
Was ist eingentlich der Hintergrund für die andere Behandlung der Dateien im Hauptverzeichnis?

[FireBird]

Und gibt es einen Trick, die Umbenennungen meiner knapp 250 Dateien zu automatisieren?

Die inf und nav auf keinen Fall, die kann man nicht zuordnen. Die TimerDiags-DB wird mittlerweile die Einträge getilgt haben, da die .recs scheinbar nicht mehr existieren. Und ohne inf kommt man auch nicht vernünftig an den EPG-Namen der Aufzeichnung. Ich habe aktuell keine Idee, wie man das machen könnte.

Was ist eingentlich der Hintergrund für die andere Behandlung der Dateien im Hauptverzeichnis?

Jeder Folder hat sein eigenes Verzeichnis auf der HDD. Da im DataFiles am häufigsten geschrieben wird, ist dort auch die Chance auf eine Beschädigung am größten.

[mecir]

[quote="FireBird"]Die inf und nav auf keinen Fall, die kann man nicht zuordnen. Die TimerDiags-DB wird mittlerweile die Einträge getilgt haben, da die .recs scheinbar nicht mehr existieren. Und ohne inf kommt man auch nicht vernünftig an den EPG-Namen der Aufzeichnung. Ich habe aktuell keine Idee, wie man das machen könnte.[/quote]

Puh, ok, dann werde ich mich via telnet anmelden, mit vi aus dem TAPSystem.log einen Satz moves für die Umbenennung erstellen und hoffen, dass es klappt. Das ist ärgerlich aber es gibt schlimmeres.

[quote="FireBird"]Jeder Folder hat sein eigenes Verzeichnis auf der HDD. Da im DataFiles am häufigsten geschrieben wird, ist dort auch die Chance auf eine Beschädigung am größten.[/quote]

Das ist jetzt für meinen Fall nicht mehr relevant, leutet mir aber nicht ganz ein.

Was spricht denn gegen die automatische Umbenennung? Die Dateien sind doch immer erstmal potentiell nicht defekt bis auf die, die aktuell im Zugriff war als die Kiste gecrasht ist. Mir hätte das viel Arbeit erspart, auch wenn z.B. lost+found allen im Hauptverzeichnis sicherheitshalber ein "test." vor den Namen gepackt hätte.

[FireBird]

Was da im Dateisystem genau kaputt geht, kann ich Dir nicht sagen. Es sieht auch so aus, als wäre das jfs_fsck in die Firmware eingebunden und die macht das so. Topfield hat das nicht selbst erfunden.

[FireBird]

V2 von lost+found ist fertig. Wer will testen? Testen, nicht sammeln! Der grundlegende Unterschied zur V1 ist, dass das TAP jetzt im Hintergrund mitläuft und sich die Namen der Aufnahmen merkt. Sollte es dann zu einem Crash kommen, kann lost+found die meisten nichtssagenden .rcn-Dateien wieder auf den Originalnamen umbenennen. Folgend die Features:

• 2 Minuten nach dem Start wird ab DataFiles ein rekursiver Scan durchgeführt und Infos zu rec, inf und nav in einer Datenbank gespeichert. Gemountete Verzeichnisse werden ignoriert.
• 3 Minuten nach dem Start wird das lost+found-Verzeichnis nach neuen Dateien überprüft und gegebenenfalls nach /DataFiles/lost_and_found verschoben. Werden die entsprechenden Infos in der DB gefunden, werden die Daten in lost_and_found auf den Originalnamen umbenannt.
• Werden Files aus lost+found verschoben, kommt ein Dialog, der den User informiert. Dieser blendet sich nach 30 Sekunden von selbst aus. Wird der Dialog nicht mittels OK oder EXIT bestätigt, kommt er beim nächste TAP-Start wieder. So wird sichergestellt, dass der Benutzer das Zurückverschieben mitbekommt.
• Wird das TAP manuell gestartet (>2 Minuten nach dem letzten Boot des Topfes), erfolgt die lost+found-Prüfung sofort.
• Alle 5 Minuten wird der Scan nach neuen Dateien wiederholt, hier aber nur im DataFiles.

Wenn jemand testen möchte, Dateinamen lassen sich auch ohne Steckerziehen „zerstören“. Wenn man Aufnahmen ins lost+found-Verzeichnis verschiebt (dafür wird der alternative ftp-Server benötigt), kann man danach via Telnet den Dateien Zufallsnamen geben:

Code: Alles auswählen

cd /mnt/hd/lost+found
for fname in *; do mv "$fname" $RANDOM.rcn; done
ls –l

Und schon sollten die Dateien zufällige Zahlen als Dateinamen und .rcn als Endung haben. Startet man danach L&F, sollten die Dateien kurz danach repariert im lost_and_found-Ordner liegen. Log liegt unter /ProgramFiles/Settings/lost_and_found.

Das TAP kann natürlich auch über TAPtoDate bezogen werden. Nicht vergessen, es nach dem Update in den AutoStart-Ordner zu verschieben, da die V1 garantiert nicht dort liegt.

[Twilight]

und danke

twilight

[Wolfman]

[mecir]

Super Sache! Hatte ja gerade kürzlich das Vergnügen in mühevoller Kleinarbeit das alles manuell zu erledigen mit sehr vielen Dateien.

Tausend Dank!

Gruß

Mecir

[macfan]

Alex, du hast immer noch wieder tolle neue Ideen auf Lager!

und

Gruß, Horst

[TV-Junkie]

Obwohl noch nie gebraucht, auch von mir vielen Dank

[ramibi]

.... und von mir auch einen Dank

[BluField62]

Testen, nicht sammeln!

danke

[macfan]

Nachdem die neue Version den TMS innerhalb kurzer Zeit reproduzierbar zum Absturz brachte, habe ich sie wieder aus dem AutoStart herausgenommen.

Gruß, Horst

[Twilight]

wenn du es reproduzieren konntest wären mehr details eventuell hilfreich

twilight

[Wolfman]

Zum TMS kann ich noch nix sagen, habe es bisher nur beim 2410 M im Autostart - und der lief heute 5 Stunden am Stück ohne Absturz.

[FireBird]

Das TAP läuft hier schon seit über einer Woche ohne Absturz.

[macfan]

wenn du es reproduzieren konntest wären mehr details eventuell hilfreich

Eine Aufnahme hat mit l+f 2.0 geklappt. Aber bei einer Wiedergabe stürzte der TMS bei drei verschiedenen Filmen kurz nach dem Start der Wiedergabe ab.

Gruß, Horst

[ramibi]

... auf meinem M auch ohne Probleme

Beim TMS kann ich es nicht sagen, solange der Ruckler hat, ist der nicht mehr am Start