Wie kann man Datum und Uhrzeit für das Dateisystem setzen?

[Homer]

Es geht mir darum, dass das Dateisystem schon beim Erstellen einer Datei das richtige Datum und die richtige Uhrzeit zur Verfügung hat.

Ich habe zwei Aufnahmen mit Datum 05.01.2000 und drei Aufnahmen mit Datum 12.01.2000. Im letzteren Fall hatte ich versucht, während der Aufnahme an den Anfang zu springen, was der Topf mit einem Reboot quittiert hat. Im ersten Fall ist das falsche Datum ohne Absturz gekommen. Automove hat mir jene Dateien auch mit diesem falschen Datum (und falscher Uhrzeit) umbenannt.

Da TAPs aktuelles Datum und Uhrzeit kennen (siehe ProgramFiles/Settings/TAPSystem.log) und TAPs auch (mit system() aus der stdlib) Unix-Befehle absetzen können, könnte ein TAP, das dieses Problem lösen kann, möglich sein. Oder ist es doch nicht machbar? Gibt es dieses vielleicht schon, oder findet sich jemand, der es programmieren kann? Ich bin auch gerne bereit, es zu testen.

Viele Grüße
Homer

[Twilight]

log dich per telenet ein....

aber rbn sollte datum und länge korrigieren.

twilight

[Homer]

[quote="Twilight"]log dich per telenet ein....

aber rbn sollte datum und länge korrigieren.

twilight[/quote]
Ich habe es eben gestartet, und rbn hat weder das Dateidatum noch das Datum im Dateinamen korrigiert.

Viele Grüße
Homer

[macfan]

Da hätten wir eine CRP-Inkompatibilität. Beim SRP funktioniert das beim Dateidatum, den Dateinamen ändert RbN nicht.

Gruß, Horst

[Homer]

Update:
Die Logeinträge von RebuildNAV zeigen "Corrected file time stamp"-Aktivitäten nur bei den von mir geschnittenen Dateien.

rbn hat bei den Dateien mit falschem Datum nichts zu rebuilden, von daher wird er auch kein Dateidatum ändern. Aber zu dem Zeitpunkt wäre es sowieso zu spät, weil Automove das falsche Datum schon in den Dateinamen übernommen hat.

Viele Grüße
Homer

[Gerti]

Hi!

Kannst mal das hier ausprobieren:

http://tms.hdpvr.de/SysTime.zip

Das TAP beendet sich direkt wieder, sollte aber die Systemzeit entsprechend setzen...

Gruß,
Gerti

[macfan]

[quote="Homer"]rbn hat bei den Dateien mit falschem Datum nichts zu rebuilden, von daher wird er auch kein Dateidatum ändern.[/quote]
Dann löschst du einfach die .nav, dann muss es klappen.

Gruß, Horst

[Homer]

Hi!

Kannst mal das hier ausprobieren:

http://tms.hdpvr.de/SysTime.zip

Das TAP beendet sich direkt wieder, sollte aber die Systemzeit entsprechend setzen...

Gruß,
Gerti

TMS Remote hat sich beim Aufruf von SysTime disconnected.

Das Display hat beim Aufruf ganz kurz einen wirren Zeichensalat gezeigt, was sich alle paar Minuten wiederholt. Das TAP wird aber nicht mehr als aktiv angezeigt.

Während einer Aufnahme wird jetzt bei allen drei Dateien das heutige Datum angezeigt.

Allerdings läuft die Systemzeit innerhalb von 20 Sekunden um 30 Minuten in die Zukunft und springt dann zur aktuellen Zeit zurück. Dann beginnt das Spiel von vorne. Die falsche Uhrzeit ist sichtbar im Unterdisplay und in den Topfmenüs rechts oben. Die Aufnahme hat dadurch auch eine falsche Uhrzeit (in der Zukunft) erhalten.

Und gerade eben ist der Topf rebootet.

Viele Grüße
Homer

[Gerti]

Hi!

Hast Recht, also scheint es wohl einen Grund zu geben, warum die Systemzeit "ungesetzt" bleibt...

Gruß,
Gerti

[Homer]

Vielleicht klappt es mit der GMT (UTC)-Weltzeit. Ich setze jetzt die Zeitdifferenz zu GMT auf 00:00 und teste erneut.

Viele Grüße
Homer

[Homer]

Das Laufen der Systemzeit trat auch bei der Zeitdifferenz 00:00 auf.

Jetzt teste ich nochmals mit 02:00 ohne andere TAPs (bis auf RemoteSwitch).

Der wirre Zeichensalat und das Reboot sind seit dem Reboot um ca. 16:15 Uhr ausgeblieben. Die Systemzeit läuft immer noch.

Viele Grüße
Homer

[Homer]

Beim Ändern des Datums (via Telnet) bricht das TAP TMSRemote die Verbindung ab:

Code: Alles auswählen

2011-06-21 17:54:44 TMSRemote: RMT: ALIVE timeout reached
2011-06-21 17:54:44 TMSRemote: RMT: Closing connection to client

Damit ist klar, warum sich TMS Remote beim Aufruf von SysTime disconnected.

Große Änderungen des Datums oder der Uhrzeit lassen die Systemzeit laufen.

Es sieht so aus, als ob man nach dem Booten die Unix-Zeit bis zu eine Stunde in die Zukunft (2000-01-01-00:59:59) stellen kann, ohne dass die Systemzeit zu laufen beginnt. Diese Grenze habe ich jetzt nicht ausgetestet. Nach elf Tagen Laufzeit ist die Unix-Zeit bei 2000-01-12 angekommen.

Wie kann man dem Topf beibringen, dass er schon elfeinhalb Jahre läuft?

Viele Grüße
Homer

[FireBird]

TMSRemote schliesst die Verbindung, wenn sich der Client 10 Sekunden lang nicht meldet. Für Zeitmaschinen wurde das TAP nicht vorgesehen.

[Happy]

Automove arbeitet beim Umbenennen nicht mit dem Zeitstempel aus dem Filesystem, sondern mit dem aus der inf Datei. Dies ist der Zeitstempel, der auch im TMS Archiv angezeigt wird.
Nur wenn dort ein 0-Zeitstempel gefunden wird, dann wird aufs Filesystem zurückgegriffen.

Oder ist die inf beim Kabelmodell schon wieder anders aufgebaut ?

Gruß,
Happy

[Homer]

Ich muss mich berichtigen: RebuildNAV hatte doch um 14:49 Uhr Datum und Uhrzeit der fünf *.REC-Dateien korrigiert. Im Log war es noch nicht sichtbar und bei den Dateien wurde das neue Datum im Filer auch nicht angezeigt (oder ich hatte nicht richtig hingesehen).

RebuildNAV hat also bei allen "alten" *.REC-Dateien das richtige Datum und die richtige Uhrzeit des Aufnahmebeginns (Beginn des Vorlaufs) gesetzt.
"2010-03-09 V3.2a Added: All rec files < 2005 will immediately receive a new time stamp"

Wieso Automove nicht das richtige Datum gefunden hat, weiß ich nicht.

Viele Grüße
Homer