Mal wieder Zeitumstellung

Das Thema gabs gestern schon (wie eiegentlich mindestens 1 mal im Jahr ), eine Lösung nicht in Sicht. Dauert vermutlich, bis die Zeitumstellung abgeschafft twird.

Timerproblem bei Zeitumstellung

Bei einem Timer zu der Stunde setze ich die Endezeit manuell auf nach drei Uhr. Lieber zu viel aufnehmen, als zu wenig.

Lars

Ach ja, den Kautionscop gibt's sonst für 5€ irgendwo auf DVD...

Lars.

Wäre es nicht auch einfach möglich kurz vor dem Beenden der Aufnahme nochmal gegenzuprüfen ob die Endezeit wirklich erreicht wurde? Wenn nicht dann wird halt noch ne Stunde aufgenommen.

Hi !

bei o.g. Aufnahme geht es nicht.. er prüft das erste mal wenn es das erste mal 2:15 Uhr ist, und beendet die aufnahme
Sicherer waers das per dauer zu machen und abschliessend den Uhrzeit-Check zu machen...

Gruss Gerd

Eine Umstellung auf Startzeit/Dauer hilft auch nichts, wie schon weiter oben geschrieben wurde.
Das Problem ist einfach, daß es die Stunde zwischen 02:00 und 03:00 Uhr zweimal gibt. Am besten sollten daher Timer, die in einer dieser beiden Stunden beginnen oder enden, spätestens um 01:59 beginnen und frühestens um 03:01 enden. Dann wird zwar unter Umständen zu viel aufgenommen, aber das ist immer noch besser als zu wenig. Da dieser Fall nur einmal im Jahr auftritt und sich auf die genannte Weise leicht umgehen läßt, möchte ich dafür auch keine aufwendige Sonderbehandlung in VDR einbauen. Falls es einem Tool, welches Timer generiert, wichtig ist, diesen Fall zu behandeln, dann kann es ja die Start/Stop-Zeiten wie beschrieben außerhalb dieser Zeit verschieben.

Sollte jemand einen einfachen Patch für die cTimer::Matches()-Funktion(en) angeben können, der eine solche Verschiebung von Zeiten, die in die "doppelte Stunde" fallen einbaut, schaue ich mir das gerne an.

Klaus

Wie kommen denn die Zeiten über EPG an? Kommen die in Lokalzeit oder in UTC?

Zitat von Mreimer

Wie kommen denn die Zeiten über EPG an? Kommen die in Lokalzeit oder in UTC?

In UTC - so steht es ja auch in der epg.data (der VDR wird dann vermutlich mal ein Jahr 2038 Problem wegen dem 32-Bit Wert für den Timestamp haben): http://vdr-wiki.de/wiki/index.php/Epg.data#E
Das Problem liegt IMHO im Format der timers.conf (und der Methode um die Wiederholungstimer zu berechnen), weil da die eindeutigen UTC-Timestamps gegen Angaben in Lokalzeit ohne DST-Markierung ausgetauscht werden.

Wenn es Richtung 2038 geht, dann könnte man hier einfach auf ein "long long" umstellen. Bis dahin sind aber noch ganz andere Dinge zu lösen, denn der Kernel an sich ist nicht 2038 fähig. Zumindest nicht auf 32bit-Systemen. Hier bin ich nach wie vor auf die endgültige Lösung gespannt, denn etliche Embedded-Plattformen laufen mit 32bit.

Wenn man die DST-Markierung mit in die timers.conf integriert, dann sollte sich das Problem aber doch lösen lassen, oder? Beim Wandeln von UTC nach Lokalzeit bekommt man diese Info geliefert und beim Abprüfen, ob die Aufnahme fertig ist, kann man diese dann wieder mit einbeziehen.

Somit würde es die Stunde von 2:00 nach 3:00 auch nicht mehr zweimal geben, denn einmal ist diese noch in DST und einmal nicht in DST. Also wenn schon kein UTC in der timers.conf, dann müsste hier definitiv das DST-Flag mit rein.

Zitat von Mreimer

Wenn es Richtung 2038 geht, dann könnte man hier einfach auf ein "long long" umstellen. Bis dahin sind aber noch ganz andere Dinge zu lösen, denn der Kernel an sich ist nicht 2038 fähig.

Diesmal denkst Du aber erstaunlich langfristig.

Was in 25 Jahren passiert…

Albert

Zumindest kann bis dahin noch eine saubere Lösung für das Problem "2038" gefunden werden.

Also zurück zum DST-Problem. Wo könnte man denn die DST-Info in der timers.conf verstecken? Ein neues Feld ganz an's Ende bauen?

Zitat von Mreimer

Also zurück zum DST-Problem. Wo könnte man denn die DST-Info in der timers.conf verstecken? Ein neues Feld ganz an's Ende bauen?

Nur um unnötige Arbeit zu vermeiden (und die eventuelle Enttäuschung): Es wird kein DST-Feld in der timers.conf geben!
Das Ganze ist kein wirkliches Problem, das irgendwelchen größeren Aufwand lohnen würde. Setzt die kritischen Timer einfach entsprechend länger und gut ist's.

Klaus

Sorry, aber im Zeitalter der Funkuhr, bzw. NTP und ähnlicher Zeitabgleichs-Hilfsmittel denkt da kein Mensch mehr dran! Wenn mich keiner drauf hingewiesen hätte, hätte ich garnicht gemerkt, dass Zeitumstellung war. Alle meine Uhren hatten sich im wahrsten Sinne des Wortes "im Schlaf" bereits umgestellt.

Wenn schon so Wurgarounds, dann sollte der VDR diese spezielle Stunde selber erkennen und automatisch die Anfangs- und Endzeit an unkritische Stellen verschieben.

Zitat von Mreimer

Wenn schon so Wurgarounds, dann sollte der VDR diese spezielle Stunde selber erkennen und automatisch die Anfangs- und Endzeit an unkritische Stellen verschieben.

Wenn VDR das automatisch machen würde, würde es etliche Anfragen geben warum der VDR auf einmal einen Timer so komisch anlegt, eventuell auch Beschwerden wenn die Aufnahmen nach manueller Änderung des Timers nicht vollständig wären.

Die einzige Lösung wäre diesen Zeitumstellungsblödsin gesetzlich abzuschaffen.

P.s.
Ich kenn Jemanden der damit überhaupt keine Probleme hat (dafür andere Probleme), der ist Hobby-Astronom und alle seine Uhren zeigen ausschließlich UTC an. Auf die Frage: "Wie spät ist es?" antwortet er: "Frag mich besser nicht danach."

Zitat von halbfertiger

Die einzige Lösung wäre diesen Zeitumstellungsblödsin gesetzlich abzuschaffen.

Natürlich. Man schafft weltweit alle Zeitumstellungen ab

Zitat von halbfertiger

P.s.
Ich kenn Jemanden der damit überhaupt keine Probleme hat (dafür andere Probleme), der ist Hobby-Astronom und alle seine Uhren zeigen ausschließlich UTC an.

Es ist ja nur ein Problem der Implementierung im VDR, weil er für eine vermeintlich leichtere aber dafür eben fehlerhafte Lösung Informationen wegwirft, die man eigentlich noch braucht... Aber die Zeitzone auf UTC zu stellen wäre in der Tat ein Workaround, bei dem das Problem nicht mehr auftreten würde (auch wenn dann die Wiederholungstimer nach der Zeitumstellung verschoben wären, aber sobald man Aufnahmen von einem Sender mit einer abweichenden Sommer-/Winterzeitregelung machen will, ist das ganze sowieso ein ziemliches Glücksspiel bei dem man sich die zukünftige Lokalzeit für den Timer ausrechnen muss)

Zitat von helau

Die einfachste Loesung waere meiner Meinung nach, vor Beenden der Aufnahme zu ueberpruefen ob man sich gerade im kritischen Zeitraum befindet (also zwischen 2 und der ersten 3 bei der Umstellung auf Winterzeit) und dann eine Stunde dranzuhaengen. Aber auf die Schnelle hab ich noch nicht gefunden wie ich das Umsetzen koennte ...

Man geht mit der aktuellen Lokalzeit nach UTC, addiert eine Stunde und dann zurück auf Lokalzeit. Wenn man dann wieder die gleiche Stunde geliefert bekommt (also nicht wie erwartet eine später), dann ist man in der kritischen Stunde.