Da ich heute im Internet auf einen älteres Blog gestoßen bin, das sich schon früher mit der Frage der Protokollierung “zuletzt gespielt” beschäftigt hat, bin ich hier noch eine Erledigungsanzeige schuldig.
Auf der Suche nach einem passenden Thread wurde ich im Archiv fündig, bei Version 4:
Eine Spalte in der DB zur schieren Anzeige dürte doch nicht allzuviel Aufwand bedeuten, oder?
(Erklärung: Ein Moderator fährt im Assist-Betrieb und will in seine Sendung spontan einige Titel aus der DB einflechten. Dann wäre eine wann-gelaufen- wie auch eine wann-läuft’s wieder- Anzeige äußerst nützlich.)
Wenn, dann ausschließlich in der v6.x (als dezenter Hinweis darauf, dass hier ein v4er-Thread aus dem Archiv aufgewärmt wurde).
Ich werde das Thema, sollte die Funktion produktiv werden, entsprechend splitten.
ich gehe aber davon aus, dass es immernoch darauf beschränkt ist, dass nur die Titel protokoliert werden die aus der Sendeplanung heraus “gespielt” werden. Einfacher: Ein Titel den ich während der laufenden Sendung über die Datenbank in die Playlist “manuel” einfüge wird nicht als “zuletzt gespielt” protokoliert.
Das würde dann den Wunsch nicht ganz fixen: (Erklärung: Ein Moderator fährt im Assist-Betrieb und will in seine Sendung spontan einige Titel aus der DB einflechten. Dann wäre eine wann-gelaufen- wie auch eine wann-läuft’s wieder- Anzeige äußerst nützlich.)
Probieren geht über studieren: Ich habe deine These soeben mittels Praxistest widerlegt.
Man nehme einen Titel im Browser über die Datenbanksuche und ziehe ihn in die Playlist. Sobald er gespielt wird (und zwar ab dem Start, noch während der Titel läuft), erscheint der Eintrag “Zuletzt gespielt” in der Bibliotheksansicht der Datenbank.
Eine Frage hab ich dazu aber noch. Dieses Feature beeinflußt aber nicht die Sendeplanung ansich oder?
Beispiel:
Die Stunde ist geplant mit weichen und harten Fixzeiten. Musikblöcke werden zur Sicherheit jeweils 5 Minuten überplant. Somit fallen eventuell die letzten ein oder zwei Titel aus der Playliste und werden vom nächsten, mit harter Fixzeit versehenden, Element überfahren.
Somit findet keine Protokollierung der zuletzt gespielten Zeit statt?
Der Shedular setzt diese Elemente aber nicht nochmals in die Folgestunde da sie bereits “geplant” waren oder?
Korrekt. Die Sendeplanung durch automatisch erstellte Playlisten bezieht sich immer auf “Letzter Einsatz” (der Datum-/Zeitstempel mit der glatten Stunde). Details folgen.
Was nicht gespielt wurde, wird auch nicht protokolliert. Allerdings bekommt es einen Vermerk ins Feld “Letzter Einsatz” - denn geplant wurde es ja. Ob es dann tatsächlich zum Einsatz kam oder nicht, ist in diesem Feld egal.
Ja und nein. Hier gehen wir in die bereits angekündigten Details.
Der Mini-Scheduler plant nicht nur von Stunde zu Stunde neu, sondern von Titel zu Titel im Musikblock.
Das bedeutet, er listet die zur Verfügung stehende Auswahl der Titel jedesmal aufs neue auf. Bereits geplante (!) Titel rutschen nach unten, da bereits “vergeben” = wie gespielt. Sonst klappt die Planung nicht.
An der Spitze der Liste der Titel stehen somit die “ältesten” = am längsten nicht gespielt geplant.
Ob sie dann auch tatsächlich zum Zuge kommen, ist nochmal eine andere Baustelle.
Konkret: Sobald ein Titel verplant wurde, ist die Wahrscheinlichkeit, in Kürze erneut zum Einsatz zu kommen, äußerst gering - aber auch nicht ausgeschlossen.
Wie das?
Einflussfaktoren können sein:
Zu wenige Elemente im Ordner, aus denen gewählt werden kann,
ungünstig eingestellte Parameter im Scheduler,
Stunden-Einschränkungen,
eng gesetzte Filter.
Wenn man sich mal in Ruhe so ein Mini-Scheduler Log anschaut (kann man im Event automatisch erstellen lassen und liegt dann im ProgramData-Verzeichnis), erkennt man, wie penibel der Scheduler alles durchrechnet und sucht, bis er ein passendes Element gefunden hat.
Mit allen Risiken und Nebenwirkungen.
Was fehlt?
Eine Option, die hardcore plant - und, wenn sie an allen Vorgaben gescheitert ist, einen Fehler auswirft mit dem Kommentar “Konnte kein passendes Element finden”.
Das gibt es teilweise heute zwar schon (z.B. wenn man versucht aus einem leeren Ordner zu wählen), aber das ließe sich verschärfen. Spätestens dann merkst du, dass deine Vorgaben zu restriktiv sind.
Ich bin sicher, dass Torben so etwas programmieren kann, allerdings weiß ich nicht, wie tief er dazu ins System eingreifen muss.
Außerdem müsste es zwei Varianten geben (also noch eine Option in der Konfiguration): Entweder soft “plane auch Titel mit Verstößen gegen die Planung ein = hohe Fehlerpunktzahl” oder hart “keine Fehler tolerieren und Sendelöcher auswerfen”.
Bitte bedenke, dass nicht jedes Radio von Stunde zu Stunde eine neue Playlist würfeln lässt, sondern ganze Tage oder oder sogar eine Woche im voraus plant. Da wäre es ungünstig, auf die Daten “Zuletzt gespielt” zurückzugreifen: Bei der Planung am Montag ist die Grundlage für den Freitag extrem dünn - schließlich gibt es ja noch keine “Zuletzt gespielt”-Einträge von Montag bis Donnerstag.
Daher ist der Wert “Letzter Einsatz” im Sinne von “in dieser Stunde eingeplant” die bessere Planungsgrundlage.
