Folgendes Problem gibt es schon länger. Nun habe ich die Ursache gefunden:
In der Playlist gibt es zwei Dummy Elemente. Infolge eines menschlichen Planungsfehler ist die FixTime des 1. Element > als die FixZeit des 2. Element’s
Resultat:
mAirList startet um 21:56:00 nicht das gewünschte 2. Element. Dummy Element wird in dieser Clock nicht mehr berücksichtigt.
Um 21:57:00 startet schlussendlich das 1. Element (Soft)
Ich würde das nicht als Bug sehen. Du hast halt mAirList gesagt, dass es das erste Elemente um 21:57 starten soll, und das tut es.
Die Fixzeiten auf aufgsteigende Uhrzeiten zu überprüfen und ggf. zu korrigieren ist keine Lösung. Stell dir vor, du hast eine Playlist mit einer Fixzeit bei 23:59:00 und einer bei 00:01:00. Da ist die zweite auch kleiner als die erste, und trotzdem ist das vermutlich so gewollt
Gemäss Zeit wäre dies auch richtig:
00:01:00 kommt nach 23:59:00
Wir haben für jede Stunde eine Clock. Somit sollte es eigentlich nur aufsteigende Fixzeiten geben.
Beispiel:
Angenommen um 12:59:00 wäre eine Element mit weicher Fixzeit geplant. Fatalerweise steht im Element 13:01:00
Um 13:00:00 müsste aber zwingend die neue Clock mit Hilfe der nächsten Fixzeit gestertet werden. Die Clock würde nicht richtig starten.
Bug?
Woher soll mAirList wissen, dass ihr nur eine Playlist pro Stunde habt und nicht eine für zwei Tage? Dann könnte man nämlich die zweite, nominell frühere Zeit, so deuten, als sei damit der nächste Tag gemeint. Was natürlich unwahrscheinlich ist, wenn sich dazwischen nicht genug Elemente befinden, um die 24 Stunden zu füllen.
Was du hier beschreibst, ist also kein Fehler. Du wünscht dir vielmehr einen Mechanismus, der einem anzeigt, wenn zwischen zwei Fixzeiten zuwenig Elemente stehen. Dann würden auch deine Zeitdreher auffallen.
Die Plausibilitätskontrolle baue ich trotzdem irgendwann mal ein. Wie gesagt, in erster Linie geht es darum zu berechnen, ob zwischen zwei Fixzeiten überhaupt genügend Material ist. Verdreher wie die von dir beschriebenen findet man dann darüber auch.
