Nicht erschrecken: Ich hab die beiden Logs von 23:50 Uhr und 00:50 Uhr von der anderen Instanz eben hochgeladen (Sollte der Log mit der Snapshot-Version sein)
Dort ist eben das gleiche passiert.
Weitere Logs kann ich später (Heute früh) hochladen, wenn die Instanzen ein wenig am laufen waren.
Danke für die Dateien. Meine neue Debug-Ausgabe ist relativ aufschlussreich. Insbesondere der ReferenceSlot, der jetzt mit im Protokoll steht.
Dabei handelt es sich um die Sendestunde, ab der die bisherige History ignoriert wird bei der Berechnung der Abstände, oder andersherum, die Uhrzeit, bis (ausschließlich) zu der die Planungsdaten herangezogen werden sollen.
Bekanntermaßen hat der Scheduler keine Zähler oder dergleichen für die Einsätze, sondern jedesmal, wenn du ihn startest, nimmt er die bisher geplanten Stunden und liest daraus den Zeitpunkt ab, zu dem die Titel das letzte Mal in Einsatz waren. Daraus ergibt sich dann die Reihenfolge für die Rotation im nächsten Planungsdurchlauf.
Der ReferenceSlot ist deshalb wichtig, weil man ja bereits geplante Stunden noch einmal neu planen, also überschreiben kann.
Beispiel: Du hast schon den ganzen Tag (Stunden 0 bis 23) geplant und willst jetzt die Stunden 16-23 nochmal neu planen. Der Scheduler soll also ab 16 Uhr nochmal neu einsteigen. Dann soll er alle bereits geplanten Stunden ab 16:00 also ignorieren und nur die bisherigen Einsätze bis einschließlich der 15-Uhr-Stunde betrachten.
In der Regel entspricht der ReferenceSlot also der ersten zu planenden Sendestunde. Bei dem Planungslauf für die 0-Uhr-Stunde um 23:50 hat das auch korrekt funktioniert:
000000 Mini Scheduler initializing
000000 Date/time: 2022-01-31 23:50:00
000000 Reference slot: 2022-02-01 00:00
Als allerdings um 0:50 Uhr die 1-Uhr-Stunde geplant wurde, stand der ReferenceSlot weiterhin auf 0 Uhr (!):
000000 Mini Scheduler initializing
000000 Date/time: 2022-02-01 00:50:00
000000 Reference slot: 2022-02-01 00:00
Das hatte zur Folge, dass bei der Planung der 1-Uhr-Stunde die geplanten Titel der 0-Uhr-Stunde komplett ignoriert und daher direkt wieder eingesetzt wurden.
Warum der ReferenceSlot falsch berechnet wurde, das müssen wir jetzt herausfinden. Ich vermute, dass irgendwo ein Rundungsfehler aufgetreten ist bei der Berechnung des Stundenanfangs basierend auf der aktuellen Uhrzeit und den Parametern des Events/Aktion. Könntest du mir bitte zum Abgleich die events.mle aus dem config-Ordner zusenden?
Übrigens gab es bis einschließlich Version 6.3.16 einen Bug, der dazu führte, dass bei der Abstandsberechnung immer versehentlich eine Stunde mehr mit betrachtet wurde als der angegebene ReferenceSlot. Diese beiden Bugs haben sich dann “günstig” überlagert, so dass das von dir beobachtete Problem erst jetzt zu Tage tritt.
Danke soweit für die ausführliche Erklärung über den Prozess und wie das zustande kam/kommt.
Klar! Ich habe sie soeben hochgeladen.
Danke. Soweit erstmal aufauffällig.
Kannst du anhand der inzwischen erzeugten Logs verifizieren, dass das wirlich genau alle zwei Stunden passiert? Also nur beim Planen von ungeraden Stunden?
Das würde dann wirklich auf einen Rundungsfehler hindeuten. Einmal rundet er korrekt auf, einmal falsch ab.
Momentan erkenne ich durch die Playlisten und den Logs der letzten Sendungs-Stunden folgendes Muster:
Lad doch nochmal die inzwischen erzeugten Debug-Logs hoch. Dateinamen kannst du so lassen wie sie sind, wir können das schon zuordnen.
Von 01:50 Uhr bis 12:50 Uhr sind nun alle Logs oben.
Danke. Wenn ich es richtig sehe, passiert es alle drei Stunden, und zwar wenn die Planung in den durch 3 teilbaren Stunden läuft (0:50, 3:50, 6:50, usw.).
Das bestätigt meinen Verdacht auf einen Rundungsfehler; auch wenn ich noch nicht ganz genau weiß warum.
Man muss dazu wissen, dass der Datentyp TDateTime von Delphi eine Fließkommazahl ist, wobei der ganzzahlige Teil die Tage sind (seit dem 30.12.1899 - warum auch immer), und der Dezimalanteil die Uhrzeit, als Teile eines Tages.
Eine Stunde entspricht also dem Wert 1/24 = 0,041666… (periodisch), und drei Stunden entsprechen 3/24 = 1/8 = 0,125. Das heißt, die Vielfachen von 3 sind die Stunden, wo der Dezimalanteil nicht periodisch ist, und das scheint irgendwie einen Rundungsfehler zu verursachen.
Wie dem auch sei, bitte probier mal den neuen Snapshot 4465. Ich habe bei der Berechungen der Stundenanfänge auf eine andere, von Delphi bereitgestellte Funktion zurückgegriffen. Vielleicht ist die nicht anfällig für das Problem.
Wenn es damit noch immer auftritt, schicke ich dir eine spezielle Debug-Version.
Alright. Hab ich noch kurz vor *:50 installiert! Daumen drücken 
Logs sagen folgendes:
000000 Date/time: 2022-02-01 13:50:00
000000 Reference slot: 2022-02-01 14:00
000000 Date/time: 2022-02-01 14:50:00
000000 Reference slot: 2022-02-01 15:00
000000 Date/time: 2022-02-01 15:50:00
000000 Reference slot: 2022-02-01 16:00
… und auch die Playlist sieht nun komplett anders aus, als um 15:00 Uhr. So wie es sein soll!
Ich find’s ja riesig, wie ihr in gemeinsamer Detektivarbeit einen Fehler identifiziert habt.
Allerdings frage ich mich, wieso das weder in meiner privaten Rotation noch bei (schätze ich) den meisten anderen Sendern bislang in dieser massiven Form aufgetreten ist.
Ich kann mich lediglich an ein Problem beim Radio von Ronny erinnern, der hatte eine ABBA-Häufung nach den Nachrichten:
Vielleicht hilft das ihm ja auch weiter?
Huhu @Schoto, 
PING!
Auch mal einen Hinweis an die Kollegen @shorty.xs und @mEGGs auf Build 4465 (oder spätestens v6.3.18, kommt aber nicht sofort).
Merkwürdig.
Mein einziges Problem ist allerdings noch, dass, obwohl die Auswahl zufällig ist, sich die Songs irgendwie immer zur selben Zeit ausspielen lassen.
Trotz niedriger Separations-Einstellungen.
Eventuell beruhigt sich dieses Problem ja jetzt nach dem Update auch. Sicher bin ich mir nicht.
So zufällig ist das eigentlich gar nicht.
Du benutzt 1,5 Ordner (ja, zwei, aber sehr verschieden gewichtet) mit gesamt ca. 300 Titeln. Die reihen sich nach dem Abspielen brav am Ende wieder ein und kommen dann, oh Wunder, wieder genau so oben an. Selbst wenn da noch ein minimaler Würfel obendrauf ist: Im Grunde wiederholen sich deine 300 Songs mehr oder minder regelmäßig in nahezu der gleichen Folge.
Zwangsläufig.
In meiner “Tagesrotation” liegen um 1.200 Titel in vier Ordnern unterschiedlicher Größe, die verschieden gewichtet in der Musikvorlage abgerufen werden. Und trotzdem kann sich am Ende des Tages das ein oder andere déjà-vu einstellen. Dann wird ein zu kleiner Ordner zu oft abgerufen oder der Scheduler möchte rundgefeilt werden.
Im Grunde ist selbst diese “normale” (Nebenbei-Hör-)Rotation noch zu klein.
Dennoch: Am Ende jedoch kommt eine gewisse Abwechslung zustande, weil die Ordner-Abrufe asynchron zueinander erfolgen und die Mischung neue Ergebnisse zutage fördert. Und ich fürchte, da klemmt es bei dir ein wenig.
Doch wo ist da der Zufall? 
Streng genommen: Nicht vorhanden.
Der Mini-Scheduler plant ja aufgrund von, mitschreiben!, Sendestunden. Soll heißen, er kennt nur die Planzeit last use 06:00:00 Uhr, und so sind die eingereiht und er sortiert die eben von oben herunter, dann ist last use 07:00:00 Uhr dran undsoweiter. Wo soll denn da bei 227 Titeln im Default-Ordner Abwechslung herkommen?
Deine Stundenvorlage zeigt “Auffüllen mit zufälligen Elementen aus dem Ordner Default”. Was soll denn da passieren? Wilder Würfel aus 227 Elementen?
Sorry, aber: Nein, das passiert nicht.
Ich fürchte, auch eine Musikvorlage würde dein Problem vorläufig noch nicht so wirklich lösen. Wäre aber mal einen Versuch wert.
Mein genereller Ratschlag: Größeres Musikarchiv, verteilt auf mehrere Ordner, aus denen die Musikvorlage variierend eine Zusammenstellung basteln kann. Dann ändern sich auch die Planzeiten und die Wiederholungsfolgen.
Danke für die ausführliche Aufklärung hinter dem System!
Ja das hab ich mir tatsächlich schon stark gedacht. Warum?
Nur bei dem Sender, wo ich NUR den Default Ordner am laufen habe, fällt es ab und an auf.
Bei den anderen Sendern/Instanzen setze ich ja noch andere Ordner ein, wie dein Vorschlag hier schon beschrieben hat. Da merkt man dann schon etwas mehr “rumgemische”.
Das stimmt wohl.
Meine Vermutung war, dass der Track-Abstand da ein wenig mitspielt, nach ausführlichem lesen hier im Forum, kam mir aber in den Kopf, dass diese Regel soweit ich weiß, nur eine weitere Sicherheit darstellen soll.
Perfekt, danke für die Rückmeldung! Ich werde hier noch etwas testen und dann eine 6.3.18 auf den Weg bringen (ist ja schon einigermaßen kritisch, dieser Bug).
Hab ich ja oben erklärt. Dieser Bug in der “Playlisten erzeugen”-Aktion wurde bislang durch einen anderen Bug überdeckt, den ich in der 6.3.17 behoben habe:
Der Scheduler muss ja bei der Initialisierung ermitteln, wann welcher Track/Interpret/Titel zuletzt gelaufen ist, bezogen auf den ReferenceSlot. Dazu gibt es eine SQL-Anfrage, die sinngemäß beantwortet: “Nenne mir für jeden Track(/Interpret/Titel) die letzte Sendestunde, in der er eingeplant war, die aber vor dem angegebenen ReferenceSlot liegt.”
Bei der Durchsicht der SQL-Anfragen war mir aufgefallen, dass dort fälschlicherweise statt < (kleiner) der Operator <= (kleiner gleich) für den Vergleich mit dem ReferenceSlot verwendet wurde. Also alle Stunden einschließlich des ReferenceSlot betrachtet wurden.
Man hätte dies daran bemerken können, dass beim Neugenerieren einer Sendestunde die dort eingesetzten Titel als “erst kürzlich gespielt” betrachtet, also nicht direkt wieder eingeplant wurden. Ist aber wohl in all den Jahren niemandem aufgefallen 
Da der falsche Vergleichsoperator so wirkte, als sei der ReferenceSlot dauerhaft um eine Stunde erhöht, hat sich andererseits auch der Bug in der Aktion nicht bemerkbar gemacht, der ja den ReferenceSlot durch Rundungsfehler um eine Stunde verringerte.
@Liam (und alle anderen, die es interessiert):
Ich habe in meiner Rotation ein nettes Beispiel gefunden, wie mAirList manchmal etwas länger suchen muss.
Pick random item from folder "2000er (Main)" (742), item count: 558, pick idx: 3
1/558: ID 6289, artist "Lido Brothers", title "Mambo Italiano"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "LIDO BROTHERS" is 1865
Title separation for "MAMBO ITALIANO" is 1865
Overall penalty is 0
2/558: ID 1446, artist "No Angels", title "Goodbye To Yesterday"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "NO ANGELS" is 5
Artist separation penalty is 2
Title separation for "GOODBYE TO YESTERDAY" is 1865
Overall penalty is 2
3/558: ID 6308, artist "Britney Spears", title "Lucky"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "BRITNEY SPEARS" is 2
Artist separation penalty is 5
Title separation for "LUCKY" is 28
Overall penalty is 5
4/558: ID 14844, artist "No Angels", title "Maybe"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "NO ANGELS" is 5
Artist separation penalty is 2
Title separation for "MAYBE" is 5
Artist separation penalty is 2
Overall penalty is 4
5/558: ID 15027, artist "Anastacia", title "Not That Kind"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "ANASTACIA" is 1
Artist separation penalty is 6
Title separation for "NOT THAT KIND" is 1
Artist separation penalty is 6
Overall penalty is 12
Maximum penalty of 5 exceeded, skipping
6/558: ID 16843, artist "Preluders", title "Everday Girl"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "PRELUDERS" is 1865
Title separation for "EVERDAY GIRL" is 1865
Overall penalty is 0
7/558: ID 6248, artist "N-Sync", title "Bye Bye Bye"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "N-SYNC" is 1865
Title separation for "BYE BYE BYE" is 1865
Overall penalty is 0
8/558: ID 6158, artist "Juanes", title "La Camisa Negra"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "JUANES" is 3
Artist separation penalty is 4
Title separation for "LA CAMISA NEGRA" is 1865
Overall penalty is 4
9/558: ID 6606, artist "Moby", title "Extreme Ways"
Last use: 2021-11-17 00:00
Track separation is 1865
Artist separation for "MOBY" is 118
Title separation for "EXTREME WAYS" is 1865
Overall penalty is 0
Pick index reached
End of search, i=9, Count=558, minPenalty=0, minPenaltyListCount=4
Picked: ID 6606, artist "Moby", title "Extreme Ways"
Aus einem Ordner mit 558 Elementen (item count: 558) sucht er aus den am längsten nicht gespielten Elementen jetzt das vierte (pick idx: 3; der Index beginnt bei 0) am besten passendste Element heraus.
Pick random item from folder "2000er (Main)" (742), item count: 558, pick idx: 3
Doch dazu müssen hier insgesamt neun Elemente herangezogen werden:
1/558
Overall penalty is 0
Erster Treffer. Merken und nach dem nächsten Treffer suchen.
2/558
Overall penalty is 2
Sorry, das wollen wir nicht. Nächster!
3/558
Overall penalty is 5
Das wollen wir ja noch weniger. Nächster!
4/558
Overall penalty is 4
Du ahnst es schon: Näch…!
5/558
Overall penalty is 12
Maximum penalty of 5 exceeded, skipping
Autsch!
Okay, der würde in diesem Durchlauf ohnehin durchfallen, aber hier greift die von mir gesetzte Notbremse.
Schön, das mal zu sehen.
6/558
Overall penalty is 0
Zweiter Treffer. Gemerkt, danke.
7/558
Overall penalty is 0
Dritter Treffer. Der nächste Treffer wird ausgewählt und die Suche ist beendet.
8/558
Overall penalty is 4
Nein, leider nicht. Noch ein Versuch.
9/558
Overall penalty is 0
Vierter Treffer - wir haben ihn!
End of search, i=9, Count=558, minPenalty=0, minPenaltyListCount=4
Meistens geht es schnell und einfach, aber das sticht mal mit allem heraus.
Ich dachte, das könnte die Community interessieren.
Was passiert eigentlich, wenn kein Element einen minPenalty=0 hat?
Dann wird der Zähler um +1 heraufgesetzt und der Durchlauf beginnt von vorn.
Was passiert mit den Elementen, die einen Overall penalty is 2 oder höher haben?
Die bleiben so lange an der Spitze der Liste stehen, bis sie unter anderen Elementen mit diesem Wert zur Auswahl stehen.
Solange es Elemente mit Overall penalty is 0 gibt, die den pick idx: [n] erfüllen, kommt der einfach nicht zum Zuge. Da muss man dann mal nachschauen, was mit dem Titel in dem Ordner los ist oder ob die Abstände so passen. Sonst bleibt der immer oben in der Liste und wird nie gewählt.
Ich finde, da hat sich Torben schon ordentlich was dabei gedacht. Ist auch sicher sehr lang “historisch gewachsen”.
Disclaimer: Meine Rotation läuft nicht 24/7 und auch nicht jeden Tag. Aber ich fordere sie zwischendurch immer wieder mal. Da lohnt sich der Blick in so ein Log auf jeden Fall.
Hm, also meinst du damit, es gibt mit Sicherheit Titel bei dir, die unberührt da rumliegen weil es halt noch “gültige” Titel gibt?
Das wäre meine nächste Frage gewesen, ob man da dann mit den Abständen rumspielen kann?
Absolut. Ich wollte damit gestern auch überhaupt nichts in Frage stellen. Ich hab nur für mich selbst eine kleine Lösung gesucht, um die Songs ein bisschen mehr zu “randomizen”, was ja gut möglich ist z. B. mit den verschiedenen Ordnern, Musikplanung, mehr Songs an sich in den Ordnern.
Dem werde ich mal im Detail nachgehen müssen. Das muss ja einen Grund haben.
Zumindest will ich wissen, warum andere Titel weniger belastet sind und einige nicht gespielt werden. Das ist ja nicht das erklärte Ziel einer möglichst abwechslungsreichen Rotation. Da hilft nur der Vergleich über acht oder zehn Stunden.
Ja klar, man kann die Abstände anpassen. Es muss ja auch irgendwie realistisch abbildbar sein.
So war das auch gar nicht gemeint. Ich habe das vielmehr zum Anlass genommen, meine eigene Automation infrage zu stellen und zu überprüfen.
Das war ein Zufallsfund, den ich als Anschauungsobjekt der Community gerne zur Verfügung stelle.
Ja, das stimmt. Von nichts kommt auch nichts, daher setz ich die Abstands-Regeln mittlerweile schon nach Gefühl.
Spannender Fund auf jeden Fall!
Also eher ein guter Startpunkt, dass wir uns darüber austauschen können. Find ich super! Findet man nicht mehr überall.
Hier noch ein paar Hintergrundinfos für Interessierte:
Es ist sogar noch ein bisschen intelligenter:
Die Liste der Titel ist aufsteigend nach Datum des letzten (geplanten) Einsatzes sortiert; zuerst die noch nie gespielten Titel, dann die am längsten gespielten usw.
Zuerst würfelt der Scheduler aus, den wievielten der in Frage kommenden Titel er nehmen wird - da ist der besagte pickIdx. 0 = der erste (Wahrscheinlichkeit 50%), 1 = der zweite (Wahrscheinlichkeit 25%) usw. Warum er das zuerst macht, werden wir gleich sehen, das hängt mit der Optimierung zusammen.
Danach geht der Scheduler die Titelliste nur ein einziges Mal von oben nach unten durch, und berechnet für jeden Titel die Penalty-Werte (wobei solche, die die Attributfilter etc. nicht erfüllen, gleich ignoriert werden). Dabei merkt er sich zwei Dinge:
minPenalty.minPenaltyList aller Titel, die diesen niedrigsten Penalty-Wert haben.Pseudo-Code:
minPenalty := unendlich
minPenaltyList := [] // leere Liste
Für alle Titel:
berechne Penalty
Wenn Penalty < minPenalty:
minPenalty := penalty
minPenaltyList := [] // Liste wieder leeren
Wenn Penalty = minPenalty:
füge Titel zu minPenaltyTitel hinzu
Nun kann dieser Durchlauf mit den ganzen Berechnungen ja sehr lange dauern, je nach Größe des Ordners. Daher gibt es eine Optimierung:
Wenn schon pickIdx+1 viele Titel mit minimalem Penalty gefunden wurden und minPenalty=0 ist, dann bricht der Durchlauf sofort ab, und der ausgewählte Titel ist der letzte in der minPenaltyLIst.
Warum? Besser als 0 kann der minPenalty ja nicht mehr werden. Und da wir schon vorher festgelegt hatten, den wievielten “besten” Titel wir nehmen wollen, können wir aufhören, sobald wird die entsprechende Anzahl gefunden haben.
Man tut also, insbesondere bei großen Ordnern, immer gut daran dafür zu sorgen, dass immer ausreichend viele “beste” Titel vorhanden sind. Was bei großen Ordnern naturgemäß meistens der Fall ist. Allerdings habe ich auch schon gesehen, dass unnötigerweise mit hohen Track-Abstand-Penalties gearbeitet wurde, wodurch es dann nie irgendwelche Titel mit 0 Strafpunkten gab.