Hallo Torben.
In dieser Kalenderwoche wurde ich darauf aufmerksam gemacht, dass um 13 Uhr in der MNST-Playliste immer der gleiche Titel an 2. Position steht (Lady Gaga - aus dem Pool “Charts-Top 20”). Alle anderen Positionen der Studenuhr haben wechselnde Titel. In der Vorwoche ist da immer ein anderer Titel an der Position in der Playliste. Die Playlisten wurden über den Scheduler erstellt (Morgen - Ein Tag - Los!).
Hast Du eine Erklärung dafür?
Solange sich der Ordnerinhalt nicht ändert, plant der Mini-Scheduler die einzelnen Titel einer Rotation immer in der gleichen (aber zufälligen) Reihenfolge aus.
Ich erwähnte ja bereits, dass das Ding einige Unzulänglichkeiten aufweist, die mit der Zeit behoben werden sollen. Dieses konkrete Problem lässt sich aber nicht lösen, ohne den Algorithmus komplett umzuschreiben, was für mAirList 3.0/3.1 nicht mehr vorgesehen ist.
Mir ist noch aufgefallen - ist aber kein Problem - dass nach einigen Generierungen auf einmal ganz viele gleiche Titel für die Stunde eingeplant werden, die auch schon in einer weiter zurückliegenden Stunde eingeplant wurden. Wie eine Art Kopie, nur dass eben doch einige andere Titel noch dazwischen sind. Beruht die Rotation ausschließlich auf Zufall?
Könnte man eigentlich noch einrichten, dass bestimmte Titel mehrmals in einem Ordner existieren können? Damit könnte man die Wahrscheinlichkeit der Einplanung, also die Rotation, eines Titel erhöhen.
Ich verwende seit gestern die neue mAirListDB (3.1) und mir ist aufgefallen, dass die Vorlagen eingefroren zu sein scheinen. Ich verwende für normale Sendestunden tagsüber immer dieselbe Vorlage und es werden bis auf ein oder zwei Titel immer die gleichen eingeplant. Was kann ich provisorisch, da es ja einen neuen Algorithmus geben soll, dagegen machen?
Ich hab jetzt nochmal ein bisschen herumprobiert. Auch wenn ich eine neue Vorlage, z.B. mit nur einem einzigen Titel aus einem bestimmten Ordner, erstelle, wird immer einer von drei bis vier Titeln aus diesem Ordner eingeplant. Auch einen neuen Titel in den Ordner zu verschieben, den Ordner also zu aktualisieren, bringt keine Besserung. Das Komische ist, dass in der alten mAirListDB-Version alles super funktionierte.
Wenn du nichts dagegen hast, schick mir doch mal bitte deine *.db-Datei, dann guck ich mir das an.
Danke für das Angebot. Die E-Mail ist in ein ein paar Minuten raus.
Danke für die Datei. Ich habe die jetzt bei mir installiert.
Sag mir doch bitte mal, bei welcher Vorlage und/oder welchem Ordner du das beobachtet hast. Dann versuche ich es hier zu reproduzieren.
Ich hab zwar noch nicht jede Vorlage ausprobiert, aber soweit ich das bisher herausfinden konnte, tritt das Problem bei jeder Vorlage auf.
Teste mal bitte Build 761, lade ich gerade hoch.
Es gab einen Bug beim Initialisieren des Schedulers. Der Wert für “Wurde zuletzt gespielt am…” wurde nicht korrekt berechnet. Das Problem hat sich daher insbesondere dann geäußert, wenn man die Playlisten einzeln (über das Dropdown-Menü neben dem “Erzeugen”-Button) generiert hat.
Super, funktioniert problemlos. Vielen Dank für den Support sogar an einem Sonntag. 
Kleine Auffälligkeit noch, die ich dir schon seit längerer Zeit mitteilen wollte:
Ich habe ein Skript, das zur vollen Stunde die nächste mAirListDB-Playlist anhängt und die letzte als gespielt markiert. Dabei kommt es zu folgendem merkwürdigen Phänomen: Bei den allermeisten Elementen wird in der Spalte “Zeit” nichts angezeigt. Bei einigen Elementen jedoch ist eine Zeit hinterlegt, obwohl die Elemente nicht zu dieser Zeit abgespielt wurden, im Screenshot unten “10:54:22” und “11:45:16”. Schaue ich in die Eigenschaften der Elemente, so ist beim ersten im Feld “Zuletzt gespielt” “Samstag, 15. August 2009, 10:54:22” hinterlegt und beim zweiten “Samstag, 15. August 2009, 11:45:16”. Dies ist noch bei einigen anderen Elementen der Fall, bei der Mehrzahl der Elemente ist das Feld “Zuletzt gespielt” jedoch frei, obwohl diese Elemente definitiv schon einmal eingesetzt wurden.
Kannst du mir das erklären? Wie kommt es zu diesen Einträgen und warum ist das nur bei bestimmmten Elementen der Fall? Und warum der 15. August?
Zunächst, vergiss mal das Feld “zuletzt gespielt”. Das wird nicht richtig gepflegt und schon gar nicht mit der Datenbank abgeglichen geschweige denn aktualisiert. Vermutlich steht da der Wert drin, der ursprünglich mal in der MMD-Datei stand und in die Datenbank gerutscht ist.
Ich werde das Feld in einer zukünftigen Version durch eine echte Datenbank-History ersetzen. mAirList 3.1 schreibt ja diesbezüglich schon ein internes Log.
Warum unter “Zeit” bei so vielen Elementen nichts steht, könnte ich am besten untersuchen, wenn du mir die Playlist in diesem Zustand mal als .mlp speicherst und zuschickst.
Okay. MMD-Dateien habe ich allerdings nie verwendet. Insofern fällt das als Erklärung aus. Aber das mit der History klingt gut.
Dass bei den anderen Elementen nichts steht ist schon richtig so. Nicht alle Stunden werden auch tatsächlich ausgespielt. Bei der Stunde auf dem Screenshot ist das auch so. Daher sollte es ja korrekt sein, wenn bei den als gespielt markierten Elementen keine Zeit angezeigt wird, oder?
Ach so, das sind übersprungene Elemente. Ja, dann ist das korrekt so.
Teilweise scheint das noch nicht ganz zu klappen mit dem Setzen des Zeitpunkts des letzten Spielens eines Elements - im Großen und Ganzen ist die Playlist gut rotiert, aber einige Titel werden mehrmals am Tag eingeplant. Könnte Abhilfe schaffen, die Musikplanung über den Mini-Scheduler zu erledigen? Derzeit erstelle ich jede benötigte Stunde einzeln über den “Erzeugen”-Button.
Aah, funktioniert doch. Fehler meinerseits, sorry.
Was war denn der Fehler?