Habe ich auch (E2 von 2007-03-12). Die größte Falle daran ist, daß bei jedem Bearbeiten des Timers die Zeit wieder um eine Stunde vorgestellt wird.

HeiRos

Hi,
kann ich bestätigen. Bei Serientimern ist das absolute Chaos vorhanden. Dabei ist es egal ob man Täglich, Mo-Fr oder Userdefinierte Tage verwendet. Die Zeit ist +1 Stunde für Start und Stop und es genügt schon wenn man in einen angelegten Timer geht und diesen mit "Ok" wieder bestätigt und die Zeit wird dan nochmals um +1 Stunde verschoben usw. usw. Nur beim Sonntag (vielleicht weil es der aktuelle Tag ist) gelingt dieses nicht.
Wenn man einen Timer von 14-15 Uhr setzen will, muss man 13-14 Uhr eingeben, in der Hoffnung dass der dann auch um real 14 Uhr anspringt.

Da die Sommerzeit ja nun wirklich nix neues ist, bin ich also extrem erstaut, dass solche Fehler noch in der Software vorhanden sind.

Noch eine Ergänzung dazu, die Anzeige vorhandener Wiederholungstimer war schon letzte Woche falsch, wenn dieser in der Sommerzeit wieder zur Ausführung kommt.

Beispiel: Ein Wochentimer der letzte Woche Mo (Winterzeit) von 20:15-21:00 lief, wurde bereits letzte Woche für diesen Montag (Sommerzeit) mit 21:15-22:00 dargestellt, was naürlich auch vollkommener Blödsinn ist.
Solange das aktuelle Datum der Box sich nicht in der Sommerzeit befindet, darf natürlich auch die Sommerzeit Korrektur bei der Anzeige eines Zukunfsttimers, der sich in der Sommerzeit befindet, nicht durchgeführt werden.

hi,

kann ich auch bestätigen, nervt ganz schön die Timer "2 Stunden" zurückstellen damit man auf die richtige Zeit kommt.

Würde sich bitte einer der Devs der Sache annehmen.

mfg
pupert

dito,

die Serientimer sind nach der Zeitumstellung verstellt und kaum zu korrigieren.

Hab mir mal den Source angeschaut und gesehen das der Timer immer davon ausgeht das der Tag 24 Stunden hat und bei den fortlaufenden Timern werden immer 24 Stunden gerechnet, da aber der heutige Tag nur 23 Stunden hat und der Timer mit 24 Stunden rechnet sind die Zeiten um 1 Stunde nachvorne verschoben.

Ab Morgen müsste eigentlich wieder alles normal ablaufen. Eigentlich ist das doch ein Bug der Timer sollte sich die Start/Endzeiten aus dem EPG holen und somit auch evtl. Programmverschiebungen mitzubekommen.

ps:
Sorry für den langen Satz.

mfg
pupert

Zitat

Ab Morgen müsste eigentlich wieder alles normal ablaufen. Eigentlich ist das doch ein Bug der Timer sollte sich die Start/Endzeiten aus dem EPG holen und somit auch evtl. Programmverschiebungen mitzubekommen.

Hi, wenn das so implementiert ist dass einfach 24 Stunden dazugezählt werden so wird das nicht so trivial, das sauber zu lösen, eigentlich müssten sich die Timer nach der Systemzeit orientieren, da diese von einem anderen Teil der SW geändert wird, müssten die Timer gar nichts mitbekommen von der Sommer resp. Winterzeit.

Das mit dem automatischen Anpassen bei Verschiebungen im EPG, haben wir hier schon als Autotimer diskutiert und würde ein Feature und keinen Bug darstellen, das andere ist natürlich ganz klar ein Bug.

Gruss 100Octane

Hmm,
dann dürfte aber das Problem doch nicht bei Timern auftreten, die erst in ein 2-3 Tagen "fällig" werden.
Zudem wird die 1+ Stunde bei jeder Veränderung des Timers addiert, egal ob der nun heute oder erst in 3 Tagen dran ist. Da wird immer noch 1 Stunde draufgepackt, egal ob der ursprüngliche Timerwert nun mit 23, 24 oder 25 Stunden berechnet wurde.
Auch die Darstellung der Sommerzeittimer, wenn die Box sich noch in der Winterzeit befindet, ist ja falsch.
Da ist meiner Meinung nach noch mehr im Argen. Die Berechnungsbasis ist schlicht falsch.

Ich würde mich da einem Vorredner anschließen wollen (anderer Thread).
Ich denke die enizig "saubere" Lösung wäre das speichern der Timer in GMT.

Beim Aufruf der Timerliste, bzw. beim Abfragen der selben müsste dann halt immer von der lokalen Zeit in GMT umgerechnet werden oder umgekehrt.

Die Zeiten in etc/enigma2/timers.xml sind GMT, und auch das WebIf gibt unter http://dm7025/web/timerlist GMT aus, dann dürfte Enigma2 auch intern damit arbeiten. Das Problem ist wohl eher, daß irgendwo bei der Umrechnung der eingegebenen lokalen Zeit in GMT diese Verschiebung um eine Stunde entsteht.

HeiRos

GMT ( aka UTC) soll die Basis für die Zeit in einem Computersystem sein, löst jedoch die Sommer/Winterzeitproblematik nicht.

Denn 20Uhr lokalzeit sind einmal UTC+1 dann UTC+2 (für unser Breitengrad).

Also ist es besser wenn sich die Timer sowieso auf lokalzeit beziehen, denn hin und herrechnen ist nicht sehr zuverlässig

Gruss 100Octane

Da bin ich etwas anderer Meinung.
Aus einer Uhrzeit in GMT in Kombination mit dem aktuellen Datum läßt sich die lokale Uhrzeit schon eindeutig errechnen, egal ob Sommer oder Winterzeit.

bekommen wir hier nochmal antwort, ob und wie dieses problem für die nächste zeitumstellung gelöst wird?

nein, das tu ich nicht
wäre trotzdem nett
weil bei der letzten zeitumstellung gab es auch fehler.

Die werden das schon fixen, keine Sorge...[/quote]

Genau diese Haltung hat mich dazu veranlasst nach einer Alternative Ausschau zu halten. Ich habe auch einen tollen Timersalat beisammen und den Eindruck, dass bei DMM die erste Zeitumstellung erfolgen sollte.

Ich dachte damals vor drei Jahren bei meiner alten 7000 auch das sie es schon fixen werden, irgendwie hab ich jetzt das gleiche Problem nur bei der 7025, weis ned ob es in Enigma 1 immernoch so ist, irgendwie lernt DMM aus alten Fehlern nicht umbedingt dazu, naja ich bin mal gespant wie es bei der nächsten Umstellung ausschaut!

MfG

Jo, wir arbeiten natürlich dran... Es ist aber wohl so, dass ihr nicht drumrum kommen werdet, die jetzt falsch stehenden Timer manuell neu zu setzen (also die Zeit bei denen halt zu ändern). Geht leider nicht anders.