Falsches Datum bei Aufnahme-Programmierung

[Hering]

Wenn ich eine Sendung programmiere, die durch den Vorlauf (z.B. 5 Minuten) genau um Mitternacht (0:00 h) mit der Aufzeichnung beginnen muss, gibt es bei einigen Vorlaufzeiten ein falsch berechnetes Datum (nämlich das des Vortages). Ich habe acht solche Programmierungen erzeugt, jeweils mit Vorlaufzeiten von 1 bis 8 Minuten und entsprechend den Sendungsbeginn um 0:01 h bis 0:08 h und jeweils den gleichen Aufnahmetag. Für 3, 5 und 6 Minuten wurde dabei das Datum falsch angezeigt, jedoch bezüglich der Sortierung im Fenster noch richtig angeordnet. Die drei Programmierungen mit der falschen Datumsanzeige habe ich dann noch nachträglich auf einen anderen Sender gelegt, so daß ein Aufnahmekonflikt entsteht und entsprechend zu roten Zeilen führte. (siehe erstes Bild: Aufnahme-Porgr sofort.png)

Dann habe ich DVBViewer Pro beendet und neu gestartet. Das bisher bei den drei (3, 5 und 6 Minuten) Sendungsprogrammierung nur falsch angezeigte Datum wurde jetzt an die dem Datum entsprechende Stelle sortiert und durch das neue Datum wurde auch der Aufnahmekonflikt behoben, d.h. die Programmierung findet einen Tag eher statt als eigentlich Programmiert. (siehe zweites Bild: Aufnahme-Prog nach beenden.png)

Warum nur bestimmte Vorlaufzeiten diesen Fehler erzeugen und wovon Abhängt warum manchmal dieser Fehler auftritt ist mir unklar. Als Fehlerursache vermute ich Rundungsfehler in der Datumsberechnung. Ein möglicher Bugfix könnte deswegen sein, da ja nur minutengenau eine Aufnahmezeit programmiert werden kann, das berechnete Datum kaufmännisch auf ganze Minuten (ganze Sekunden sollten es auch tun) zu runden, da ich annehme, daß das Datum durch einen Rundungsfehler nur einen Tick (100 ns) vor Mitternacht gelandet ist.

 

support.zip

Edited June 24, 2020 by Griga
Titel korrigiert: Flasches -> Falsches

[Griga]

vor 57 Minuten schrieb Hering:

Ich habe acht solche Programmierungen erzeugt, jeweils mit Vorlaufzeiten von 1 bis 8 Minuten und entsprechend den Sendungsbeginn um 0:01 h bis 0:08 h und jeweils den gleichen Aufnahmetag. Für 3, 5 und 6 Minuten wurde dabei das Datum falsch angezeigt,

 

Stimmt, das kann ich mit dem DVBViewer Pro 6.1.6 reproduzieren. In der aktuellen Entwicklungslinie ist der Fehler jedoch verschwunden. Wahrscheinlich versehentlich gefixt Ich schaue mal wo der Unterschied im Code liegt... wenn ich die Lösung habe, werde ich eine Version mit dem Fix in die Beta Section des Mitglieder-(Download-)Bereiches hochladen und hier Bescheid geben.

 

vor einer Stunde schrieb Hering:

Als Fehlerursache vermute ich Rundungsfehler in der Datumsberechnung.

 

Das vermutest du richtig. Es ist nicht das erste Mal, dass es mit Aufnahmen, die um 00:00 beginnen, Probleme gibt. Ursache ist immer wieder, dass Delphi (d.h die verwendete Entwicklungsumgebung) Zeit/Datum als Fließkommawert kodiert:

 

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_TDateTime.html

 

IMO ein sehr unglückliche Entscheidung. In meiner privaten Entwickler- und Probierversion DVBViewer GE habe ich deshalb ein eigenes System entwickelt, dass Zeit/Datum als 64-Bit-Ganzzahlwerte kodiert. Da passiert sowas nicht. Allerdings hatte ich bislang nicht die Nerven, den gesamten DVBViewer Pro und Media Server darauf umzustellen. Das wäre eine Heidenarbeit.

 

Danke jedenfalls für die ausführliche systematische Untersuchung des Problems. Sowas ist sehr hilfreich.

 

[Griga]

Der DVBViewer Pro-Fix ist in der Beta Section des Mitglieder-(Download-)Bereiches erhältlich. Bitte die ReadMe lesen!

 

[Hering]

Sollte der Bug doch nicht durch Zufall bereits behoben sein, würde ich empfehlen bei der Erzeugung jeder Uhrzeit einfach ungefähr 1 Millisekunde bzw. ungefähr 1.16e-08 auf den Zeitpunkt aufzuschlagen. Da der DVBViewer im Bereich der Minutengenauigkeit arbeitet und bereits ein Bild im Viedostream ca. 40 ms braucht, spielt diese kleine Differenz keine Rolle, die Zeiten sind so aber gegen Rundungsfehler gestählt. Dabei muß beachtet werden: TDateTime als Uhrzeit immer mit 1 ms Aufschlag erzeugen, Zeitspannen (z. B. Vorlauf) immer ohne solch Aufschlag erzeugen. Wichtig ist, das es einem nicht passieren darf, daß immer wieder der Aufschlag aufaddiert wird. Als Mathematiker habe ich das mal in Numerik gelernt, da hat man es ja immer mit diesen Gleitkommazahlen zu tun und bei Differenzen können die sonst ziemlich fies sein.

[Richter]

Soeben aufgefallen:

Mit dem 6.1.6.10 Fix wird eine Sendung, die um 0:00 Uhr beginnt und mit einer Minute Vorlauf aufgenommen werden soll, jetzt für 0:01 programmiert, also genau verkehrt.

Bei der Vorversion 6.1.6.9 noch korrekt für 23:59.

[Griga]

vor 9 Stunden schrieb Richter:

Mit dem 6.1.6.10 Fix wird eine Sendung, die um 0:00 Uhr beginnt und mit einer Minute Vorlauf aufgenommen werden soll, jetzt für 0:01 programmiert, also genau verkehrt.

 

Oha! Stimmt.

 

Ich hatte in der 6.1.6.10 auf die Ergebnisse von Startzeit minus Vorlauf bzw. Endzeit plus Nachlauf eine schon seit Jahren im DVBViewer vorhandene Funktion angewandt, die auf Minuten rundet, indem sie Zeitwerte mit Hilfe der Runtime-Bibliothek erst in Stunden, Minuten, Sekunden und Millisekunden als Ganzzahlen zerlegt (unter Ausbügelung von Rundungsfehler-Abweichungen) und dann die Stunden und Minuten wieder in einen Fließkomma-TDateTime-Wert zurückverwandelt. Das entsprach der Vorgehensweise in der aktuellen DVBViewer-Entwicklungslinie und behob das von @Hering beschriebene Problem.

 

Allerdings kann diese Funktion nicht mit negativen Zeiten umgehen, die bei 00:00 Uhr minus Vorlaufzeit entstehen. Sie liefert dann eine positive Zeit zurück. So kommt es zu dem neuen Problem.

 

Also ein weiterer Versuch, jetzt mit einer Funktion, die den TDateTimeWert erst in eine entsprechende Anzahl Minuten umrechnet, das Ergebnis auf eine ganze Zahl rundet und diese wieder in einen TDateTime-Wert zurückverwandelt. Bei allen meinen Tests führte dies zu korrekten Angaben (auch bei Timern, die mit Nachlaufzeit um 00:00 Uhr enden). Kurz gesagt werden so alle Zeiten einheitlich durch eine entsprechende Anzahl Minuten geteilt durch die Anzahl Minuten pro Tag als TDateTime-Fließkommawert angegeben.

 

Das Ergebnis ist als DVBViewer Pro-Fix 6.1.6.11 im Mitglieder-(Download-)Bereiches erhältlich. Mal sehen, wo das wieder schiefgeht