Scheduler plant manchmal die falsche Stunde - "Reference slot xx:59"

Nils_InfiniteRadio · November 28, 2023, 9:14am

Hallo Zusammen,

in meinem Hobbyprojekt läuft derzeit mAirList 7 im Testbetrieb für eins dieser Webradios mit Stunde-zu-Stunde-Planung (ja ja, ich weiß…) über den mAirList Scheduler.
99% der Zeit funktioniert das gut. Hin und wieder aber kommt es vor, dass der Scheduler unerwartete Dinge tut, die dann zum Leerlauf führen.

Heute früh war es wieder soweit:
Bei der Generierung um 08:05 war der “Reference slot” im Debuglog plötzlich mit “07:59” angegeben, statt wie erwartet “09:00”. Ich nehme an, deswegen hat er versucht erneut die Stunde 7+1==8 zu planen.
Die Stunde-9-Playlist war dann dementsprechend leer, und das hat um kurz nach 09:00 Uhr zum Leerlauf geführt.

Ja, die von mir dafür eingerichteten Warn-Emails haben funktioniert, und man könnte durch großzügige Anwendung von Wiederholungsversuchen evtl. die Auswirkungen solch eines Fehlers reduzieren.
Ich würde aber trotzdem gern verstehen wieso das passiert, weil das schon ein paar mal aufgetreten ist und auf ein systematischeres Problem hinweist, evtl. einen Bug.

Zur Konfiguration:
Derzeit Build 5432, die Datenbank ist auf dem Playoutserver lokal.
Es gibt zwei geplante Tasks, die den Ablauf steuern:

Um :05 wird die Playlist für die Folgestunde generiert (“Anzahl der Stunden, für die Playlisten generiert werden sollen”==1, “Aktuelle Stunde mit einbeziehen” == aus)
Um :10 wird die Folgestunde-Playlist hinten angehängt

Zum Vergleich der Kopf des Scheduler-Debuglogs von 07:05 - hier ist alles ok:

000000  Mini Scheduler initializing
000000  Date/time: 2023-11-28 07:05:00
000000  Reference slot: 2023-11-28 08:00

Dann um 08:05, plötzlich ist der “Reference slot” 07:59?!

000000  Mini Scheduler initializing
000000  Date/time: 2023-11-28 08:05:00
000000  Reference slot: 2023-11-28 07:59

Auch sind manche “Last Use” Angaben in diesem Log im “:59” Format.
Ich erkenne dort kein Muster:

000422  3023        Permanating                               Last use: 2023-11-26 10:59
000422  4408        Radar Love (UK Single Version)            Last use: 2023-11-26 10:59
000422  4402        Don't Bring Me Down                       Last use: 2023-11-26 10:59
000422  3847        Layla                                     Last use: 2023-11-26 12:00
000422  1727        T.N.T.                                    Last use: 2023-11-26 12:59
000422  4876        Our House                                 Last use: 2023-11-26 15:59
000422  4812        Gimme All Your Lovin'                     Last use: 2023-11-26 18:00
000422  2893        Funk Heven                                Last use: 2023-11-26 18:00

Und von 09:05, wieder alles ok:

000000  Mini Scheduler initializing
000000  Date/time: 2023-11-28 09:05:00
000000  Reference slot: 2023-11-28 10:00

Sachdienliche Hinweise die zur Ergreifung des Fehlers führen werden gerne angenommen

uli.mairlist · November 28, 2023, 10:54am

Hallo und herzlich willkommen im Forum und der Community.

Vielen Dank für die Meldung. Ich habe das im internen System aufgenommen und leite das weiter; allerdings kann sich das krankheitsbedingt verzögern.

Eine Frage vorab:
Hat jede deiner Planstunden (Stundenvorlage) die Marker “Stundenanfang” und “Stundenende”?

Randnotiz:

No excuses!
Wir empfehlen tatsächlich die Stunde-zu-Stunde-Planung mit “Playlist anhängen”.

Es gibt sicher auch Stationen, die sich einen gesamten Sendetag in die Playlist laden, aber davon raten wir aus langjähriger Erfahrung eher ab.
Möglich ist natürlich beides.

Nils_InfiniteRadio · November 28, 2023, 11:09am

Hallo Uli,

danke

Der Stundenanfang mit Soft-Fixtime ist in jeder Playlist vor dem ersten Musikblock zwar vorhanden, allerdings ist bei den Tagsüber-Stundentemplates (05:00-20:00) noch das “Nachrichten & Wetter” Element davor.
Der Grund: Für Laut.fm spiele ich das bereits um :59:00 aus, um die 60 Sekunden Delay zu kompensieren. Stundenende habe ich momentan keines drin.
Sind die denn beide technisch notwendig?

uli.mairlist · November 28, 2023, 11:12am

Vorschlag: Probiere es mal mit Stundenende, auch soft fixed time.
Dann hast du einen Marker.

Das letzte Element wird auf jeden Fall ausgespielt (im Zweifelsfall auf Backtiming setzen), auch wenn es in die neue Stunde hineinragt. Die nachfolgende Überplanung fällt dann hinten runter.

Nils_InfiniteRadio · November 28, 2023, 12:19pm

Alles klar, ist umgesetzt.

Stefan_Hillen · November 28, 2023, 12:40pm

Löst zwar nicht Dein Problem, aber…

Als alter laut.fm-User möchte ich anmerken, dass der Aufwand eigentlich vergeblich ist. Durch den systembedingten Versatz, der durch die individuelle lokale Werbung entsteht, hört jeder Nutzer Deinen Stream komplett anders zeitversetzt, bis zu fünf, sechs Minuten sind dabei je nach ununterbrochener Hördauer nach Erfahrungen der User wohl drin.

Interessante Zeiten. Gibt es einen Grund, warum das Anhängen (und Generieren) so früh und nicht erst irgendwo zwischen :50 und Stundenende passiert?

Stefan_Hillen · November 28, 2023, 12:43pm

Ach ja, schon gewusst: Du kannst die mAirlist-interne Uhr auch vorstellen und so die Verzögerung des Streams kompensieren. Einfach unten rechts auf die Uhr klicken und eine andere Zeit eingeben, dann richtet sich mAirlist danach aus.

So kannst Du trotzdem normal auf :00 planen - sollte sich der Versatz mal ändern, musst Du so nicht alle Stundenvorlagen anpassen…

Liam · November 28, 2023, 12:53pm

Ich fange z. B. schon um XX:40 an die Playlisten zu generieren. Mir sind gelegentlich aus dem Nichts Sendelöcher reingesprungen sobald ich die Folgestunde um XX:50 generieren lasse und durch das “zu frühe generieren” verhindere ich das sowieso…

Sprich es war gelegentlich (Nicht oft aber alle paar Wochen/Monaten) so, dass sich mAirList bei mir um XX:47 Uhr meldete mit “Playlist ist leer gelaufen”. Kam seit der Umstellung auf XX:40 nicht einmal wieder vor.

Aber vielleicht sind meine Stundenvorlagen auch nicht zu 100% angepasst.

uli.mairlist · November 28, 2023, 1:00pm

Nur hat all’ das nichts mit dem beschriebenen Phänomen zu tun, auf das wir uns nach wie vor konzentrieren sollten. Wenn sich da wirklich ein verstecken sollte, dann helfen uns die gezielten Angaben von @Nils_InfiniteRadio weiter.
Immerhin läuft bei ihm ja keine Playlist leer.

Torben · November 28, 2023, 2:41pm

Es handelt sich hier mit ziemlicher Wahrscheinlichkeit um Rundungsfehler, die in der Art begründet liegen, wie Delphi intern Datum und Uhrzeit speichert, nämlich im Typ TDateTime, der im Grunde eine Dezimalzahl (mit Nachkommastellen) ist.

Dabei gilt:

Der Wert 0 entspricht dem 30.12.1899 00:00:00 Uhr (willkürlich definiert).
Ein Schritt von einem Tag entspricht dem Wert 1. Also ist 1 = 31.12.1899, 2 = 01.01.1900 usw.
Stunden, Minuten, Sekunden usw. werden dementsprechend als Bruchteile von 1 dargestellt. Also ist 1/24 = eine Stunde, 1/(24*60) = 1/1440 = eine Minute usw.

Das Problem ist, dass der Rechner intern mit Gleitkommandarstellung arbeitet, also die Zahlen nicht als Brüche speichert, sondern in Dezimaldarstellung mit einer bestimmten Anzahl Nachkommastellen. Und das ist ein Problem bei Werten, die eine periodische Dezimaldarstellung haben, denn da wird was abgeschnitten. Und wenn man dann anfängt, mit den Zeiten herumzurechnen, treten Rundungsdifferenzen auf.

Vereinfachtes Beispiel:

Acht Stunden = 8/24 = 1/3 = 0.3333333…
Der Rechner kann aber z.B. nur vier Nachkommastellen speichern: 0.3333 (in Wirklichkeit sind es mehr)
Wenn man jetzt 3*8 Stunden rechnet: 3x0.3333 = 0.9999

Auf diese Weise landet man dann plötzlich eine Sekunde vor der vollen Stunde. So etwas ähnliches wird da passiert sein.

Ich muss jetzt herausfinden, an welcher Stelle ich eine zusätzliche Rundung auf die volle Stunde einfügen muss, damit das vermieden wird.

Ist das v7.2 oder schon v7.3?

Nils_InfiniteRadio · November 28, 2023, 2:46pm

7.2, Build 5432

Liam · November 28, 2023, 3:14pm

Ganz kurze Frage: Ist das ein ähnliches Problem wie hier: Wiederholungen der Stunden/Tracks - Deutsch / German / mAirList 6.x - mAirList Community Forum?

Torben · November 29, 2023, 4:33pm

Ja, in der Tat, das ist exakt dasselbe Problem. Danke für die Verlinkung, ich hatte nicht auf dem Schirm, dass wir das damals schon so genau seziert haben. Leider scheine meine Lösung ja nicht in allen Fällen zu helfen…

@Nils_InfiniteRadio: Ich schicke dir gleich per Mail einen Link zu einer Debug-Version. Bitte ganz normal als Setup drüberbügeln. Dann warten, bis das Problem wieder auftritt.

Danach schaust du bitte im Systemprotokoll nach, oben links unter “Filter” noch “Debug” aktivieren, und dann solltest du zusätzliche Einträge sehen:

Die Hex-Werte hinter den Zahlen interessieren mich besonders. Tipp: Du kannst die Einträge mit Strg+C kopieren und dann als Text/JSON hier im Thread einfügen, das ist hilfreicher als ein Screenshot, da ich mir die Werte dann direkt rauskopieren kann.

Torben · December 14, 2023, 1:45pm

Problem sollte ab Version 7.2.4 behoben sein, Details hier: