Jump to content

Zeitumstellungsproblem in der aktuellen Version


Recommended Posts

Posted

Alle Timer, die ich mit dem DVBViewer vor der Zeitumstellung aus dem EPG heraus für einen Zeitpunkt nach der Zeitumstellung erzeugt habe, wurden einen Stunde zu früh eingetragen.

 

Mir war das schon aufgefallen, aber ich dachte, naja, das wird sich irgendwie zum Zeitpunkt der Umstellung korrigieren. Tut es aber natürlich nicht. Würde ja auch nicht funktionieren, weil die vom TVinfo-Import erzeugten Timer richtig eingetragen wurden.

 

Also kontrolliert eure Timerlisten, ob alles richtig eingetragen wurde.

Posted

Mir ist dasselbe passiert. Ein paar Aufnahmen haben dadurch natürlich dann auch "nicht funktioniert". Und das korrigieren der restlichen programmierten Aufnahmen war auch lästig. Das ist schon etwas ärgerlich. Mir ist das leider zugegebenermaßen schon bei der letzten Zeitumstellung passiert, habe dann aber nichts unternommen.

 

Könnte man das nicht in den Griff bekommen? So etwas sollte doch automatisch richtig funktionieren. Eine Warnung wenn man Aufnahmen programmiert, die nach einer bevorstehenden Zeitumstellung liegen, wäre das Mindeste. Und eine Anleitung wie man es richtig macht.

Posted

In der Hinsicht habe ich bereits etwas unternommen:

 

http://www.DVBViewer.tv/forum/topic/8569-DVBViewer-ge/page__view__findpost__p__322892

 

aber die Umstellung iat ziemlich aufwändig und wurde deshalb noch nicht im DVBViewer Pro / Recording Service durchgeführt. Außerdem musste sich erst mal zeigen, ob das so im DVBViewer GE funktioniert. Zwar hatte ich für Tests eine Simulation verwendet, die dem Programm z.B. am 12. Dezember eine Umstellung auf Sommerzeit und am 13. wieder zurück vorgaukelte (was soweit klappte, nur das Wetter zog leider nicht mit...). *Wirklich* testen lässt es sich jedoch nur zweimal im Jahr. ;)

Posted

Hallo Griga,

 

es freut mich, dass an einer Lösung gearbeitet wird. Damit kann ich sehr gut leben und sehe der nächsten Zeitumstellung gelassen entgegen.

Posted

Wenn die Anfangszeit des Timers vor der Umstellung liegt und die Endzeit nach dem Timer, dann ist das sicherlich kniffelig.

 

Aber einfach alle Timer nach der Umstellung eine Stunde zu früh einzutragen, dass ist schon ein eindeutiger Fehler und sollte nach so vielen Zeitumstellungen (seit es den DVBViewer gibt) eigentlich nicht mehr vorkommen. Auch wenn das mit den Zeitzonen immer so eine Sache ist.

 

Nachdem ich bei der ersten Zeitumstellung mit dem DVBViewer auch einige Aufnahmen verloren habe, bekommen bei mir alle Aufnahmen in der Umstellungsnacht zusätzlich eine Stunde Vor- und Nachlauf. ;-)

Posted

Mir war's auch aufgefallen. Und zwar waren alle Zeiten, die im EPG eingetragen waren, bereits um eine Stunde verschoben.

 

Beispiel: rbb, "Der Pauker", Sendezeitpunkt 09:00, aber laut EPG 08:00. Anderes Beispiel: mdr, "Bei Oscar ist 'ne Schraube locker", Sendezeitpunkt 06:40, aber laut EPG 05:40. Festgestellt gegen 01:30. Kein Wunder, daß der Timer falsch geht, wenn bereits die EPG-Zeiten falsch sind. Ein Glück hab' ich es gemerkt und die Zeiten um eine Stunde korrigiert.

 

Übrigens: jetzt 12:30, stimmen die EPG-Zeiten wieder.

 

Gruß

 

akapuma

Posted
Wenn die Anfangszeit des Timers vor der Umstellung liegt und die Endzeit nach dem Timer, dann ist das sicherlich kniffelig.

Eigentlich nicht. Bei der koordinierten Weltzeit (UTC), mit der der DVBViewer GE neuerdings intern arbeitet, gibt es ja keine Zeitumstellung. Die gesendeten EPG-Zeiten sind ebenfalls UTC, und Windows erlaubt die Abfrage der Systemzeit als UTC. Wenn man also Timer über den EPG programmiert, kann theoretisch nichts mehr schiefgehen.

 

Für die Umrechnung UTC -> lokale Zeit zwecks Anzeige im UI müssen natürlich die Umstellungszeitpunkte berücksichtigt werden, die sich von Windows abfragen lassen. Das ist jedoch relativ unkritisch, da eindeutig.

 

Wirklich kompliziert wird es, wenn der Anwender manuell *lokale* Zeiten im UI eingibt/korrigiert, die in UTC umgerechnet werden müssen. Sie können ungültig sein (Umstellung Winter -> Sommer, 2:30 gibt es nicht), oder mehrdeutig (Umstellung Sommer -> Winter, 2:30 gibt es doppelt). Die Dauer ist nicht zwangsläufig lokale Endzeit minus lokale Startzeit, die lokale Endzeit kann sogar vor der Startzeit liegen (Umstellung Sommer -> Winter, Sendung von 2:30 bis 2:15 mit 45 Minuten Dauer) usw. Man muss sich darüber im Klaren sein, dass diese Fälle auch für den Anwender etwas gewöhnungsbedürftig werden. ;)

 

Auch die Tatsache, dass auf der Südhalbkugel in unserem Frühling auf Winterzeit und in unserem Herbst auf Sommerzeit umgestellt wird (also genau umgekehrt), hat mir einiges Kopfzerbrechen bereitet - und gerade ich muss sowas programmieren, wo ich doch schon bei unserer Zeitumstellung regelmäßig desorientiert bin... :wacko:

 

Am einfachsten wäre es, wenn man den Zeitumstellungs-Unfug weltweit abschaffen würde (auch im Interesse unserer Milchkühe). Was dieses Thema bereits an IT-Arbeitsstunden verbraucht hat und in Zukunft verbrauchen wird, geht auf keine Kuhhaut.

Posted

Wenn man also Timer über den EPG programmiert, kann theoretisch nichts mehr schiefgehen.

Praktisch aber schon - siehe meinen Post zuvor.

 

Gruß

 

akapuma

Posted
Wenn man also Timer über den EPG programmiert, kann theoretisch nichts mehr schiefgehen.
Praktisch aber schon - siehe meinen Post zuvor.

Hast du das letzte DVBViewer GE-Release mit interner UTC-Verarbeitung benutzt? Vermutlich nicht... bitte noch mal etwas sorgfältiger lesen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...