Abstand Interpret Mini Scheduler

Die Weihnachts-Anomalie würde ich hier ausschliessen. Alle Titel die hier gespielt werden, sind im Wochenprogramm verstreut, werden lediglich am Dienstag für (ich meine 8 oder 10 Stunden) Besonders intensiv geplant.


Ist bei allen 3 Titeln identisch eingestellt.

Als ich das gerade nachsehen wollte ist mir etwas merkwürdiges aufgefallen.
Ich finde die Münchener Freiheit nicht in der Interpretenliste.


Müsste doch eigentlich unte “Mu” mit einsortiert sein. (Später herausgefunden “Mü” steht am Ende der Liste, sollte mal gefixt werden)
Weiter oben Mr. President feat. Münchener Freiheit sollte ja über das Rihanna Feature entsprechend mit gewichtet werden.
Nebenfrage: Warum kann ich im Interpreten Baum durch tippen auf der Tastatur eigentlich nicht zum entsprechenden Buchstaben springen? An der Treeview Komponente kann es nicht liegen, ich habe in meiner Ausspielung mein MP3 Rootverzeichnis eingebunden, da geht das nur bei allem was mit Datenbank zu tun hat, irgendwie nicht.
Ich meine sows ähnliches hatten wir schon mal mit dem Doppelklickverhalten. Wenn ich eine Datei doppelklicke wird sie am Ende der Playliste oder beim markierten Element in der Playliste eingfügt, aus der Datenbanksuche heraus, geht das nicht.
Zurück zum Thema.



Ich habe mal zufällig einen anderen Titel aus dem Pool gegriffen.

Wir bekommen nächsten Dienstg ja die Detaillierten Logs, danach werden wir diesen Wert sicherlich verändern. Wir hatten bisher keine Anhaltspunkte, was hier ein vernünftiger wert ist und im großen und ganzen ist der UKW Effekt (ich höre gefühlt jeden Tag zur gleichen Zeit die gleiche Musik und das 10 mal am Tag) bisher ausgeblieben. Daher gab es nicht die zwingende Notwendigkeit, hier etwas zu setzen.
Aber ja, das macht schon Sinn, man muss es nur richtig einstellen.

Danke! Das hatte ich tatsächlich nicht auf dem Schirm, dabei ist das ein Mega Feature.
Rechte Maustaste auf den Ordner und dann im Tab Scheduler, den HAken setzen, vorher ist das Feld leer. @mEGGs, schaut euch das mal genauer an.

Ich denke, dass sich in letzter Zeit ein Fehler in mAirlist eingeschlichen hat. In den letzten Wochen gab es mehrere Benutzer, die dieses Fehlverhalten des Mini Schedulers gemeldet haben.

https://community.mairlist.com/t/artist-almost-back-to-back-despite-artist-separation/15322

Ich benutze mAirlist jetzt seit fast zehn Jahren und bin bis jetzt noch nie auf dieses Problem gestoßen. Obwohl ich zugeben muss, dass das Problem in den letzten Wochen nicht aufgetreten ist. Das muss es ziemlich schwierig machen, es zurückzuverfolgen. In meinem Fall fing es irgendwann Mitte des Dezembers an.

(übersetzt mit Google Translate)

1 Like

Hallo @shorty.xs,

danke für die ausführlichen Screenshots. Torben schaut sich das nochmal an.

Generell aber scheint euer Problem vielschichtig(er) zu sein, doch dazu muss ich mich erst noch näher einfuchsen. Mal abwarten, was Torben sagt wenn er aus den Tiefen des Codes zurück ist.
Danach gehen wir beide in die Analyse, okay?

Dass das nicht mal eben zu finden ist, war mir schon klar.
Nächsten Dienstag könnte das wieder auftreten und dann bekommen wir zumindest ein Debug-Log, ich schätze mal damit kommt man erst wirklich weiter.

Lass’ Torben erst mal noch was im Code prüfen (Delphi at it’s best), danach komme ich noch mal auf dich zu.

Im übrigen kann man Sendestunden ja auch vorplanen, ohne die Eventverwaltung zu stören, dann hättest du den Test schon jetzt. Aber warte erst mal noch ab, bevor ich dir grünes Licht für die Vorplanung gebe.

Jaein, ich würde tatsächlich bis Dienstag warten. Denn einzelne Titel werden ja über die Woche immer mal wieder eingeplant. Würde ich also vorab den Tag würfeln, bekomme ich ggf. ein anderes Ergebnis.
Wir würden ja unbekannt viele Parameter verändern. Da wir nur ein Pro-Lizenz haben, kann ich auch nicht auf einem Clone der Datenbank arbeiten.
Der Fehler tritt ja ziemlich reproduzierbar auf, wie man an der Historie sieht nur verschoben um ein paar Stunden.

Ja, das stimmt.
Hinsichtlich der Planung habe ich da ohnehin noch ein paar andere vermutungen, was euch betrifft. Wie ich schon sagte: Wahrscheinlich vielschichtig.

Du weißt, ich habe euch mal (als Hörer) sehr intensiv im Fokus gehabt und da fällt einem schon die ein oder andere Sache auf, die ich vermutlich im Bereich der Stundenvorlage verorten würde.
Das habt ihr aber vermutlich schon längst im Fokus. :slightly_smiling_face:

Uff, hier hat sich ja was getan. Respekt ich muss hier öfter mal mitmachen :blush:
Bin gespannt was wir dazu rausfinden.
@shorty.xs @UliNobbe das mit den Strafpunkten auf Ordnerebene ist natürlich cool, das setzen wir sicher ein.

Jep haben wir Uli. Das muss überarbeitet werden, ist aber aktuell sehr rudimentär gelöst. Es gibt im Prinzip nur eine Stundenvorlage die einen Anfangsbefehl zur Stunde setzt (wir steuern darüber die Sende-Grafik auf der Homepage), dann kommt ggf. noch ein Jingle und dann Block auffüllen mit Musik 30 min., wieder Jingle (bestimmter Jingle in dem Beispiel mit Einschränkung auf Samstag/Sonntag) und dann unendlich auffüllen mit Musik bis neue Stunde kommt. Unendlich ist hier gewählt, damit niemals ein Sendeloch entstehen kann.

Die Musikvorlage dahinter sieht dann z.B. so aus(wir verwenden natürlich verschiedene)
grafik

offtopic:
Die Stundenvorlagen können viel mehr, ist bewusst und wird nach und nach mehr rausgeholt.
In Planung haben wir mehr mit Attributen zu arbeiten, also die Jahrzehnte an die Titel pflegen z.b. statt über Ordner zu gehen (ich weiß hab irgendwo gelesen, dass du aktuell eher zu virtuellen Ordner rätst weil da noch eine Entwicklung von Torben onGoing ist) Um einen schöneren “Flow” zu bekommen pflegen wir noch Geschwindigkeiten und Stimmungen der Songs. Ist halt erstmal viel Arbeit aber wir glauben an ein richtig gutes Ergebnis :nerd_face:

Anregungen, Feedback gerne. Habt ein schönes Wochenende

Hallo @mEGGs,

das machen wir in Ruhe mal auf einer anderen Ebene.
Danke für die Transparenz.

1 Like

So, nach eingehender Analyse kann ich folgendes berichten:

  • Es gab einen Bug, der dazu führte, dass die Abstandsberechnungen nicht korrekt waren, wenn (kleine) Umlaute im Interpreten oder Titel vorkamen. Intern werden, um unterschiedliche Schreibweisen zu ignorieren, alle Strings in Großbuchstaben gewandelt. Delphi bietet dazu zwei unterschiedliche Funktionen (das gute alte UpperCase und das neue ToUpper), die ich gemischt benutzt hatte, im Glauben, sie würden dasselbe tun - stimmt aber nicht, eine von beiden hat kleine Umlaute klein gelassen, nur die andere hat das ü in ein Ü verwandelt.
  • Ein zweiter Bug betrifft die Ausgabe im Debug-Log, da standen bei “Artist seperation for xxx is yyy” immer falsche Werte (Sollwert+1 statt Istwert).

Beides ist im neuen Snapshot 4460 behoben. Bitte testet den eingehend, ich musste etwas ans “offene Herz” und hoffe, dass ich alles heile gelassen habe.

Weiterhin:

  • Was die Sortierreihenfolge im Baum angeht, die wird durch den SQL-Server vorgegeben. Bitte prüft mal, was eure Datenbank für eine Collation hat.
4 Likes

Mit dem heute erschienenen Snapshot, Build 4460 (4461) wurde das auch noch so nebenbei geändert:

Jetzt ist aber mal Wochenende für Torben! :sunglasses:

3 Likes

Jou, da muss ich wohl noch mal ran. Lässt sich anscheinend nicht auf einer laufenden Datenbank umstellen. Dumpen, neu anlegen und wieder importieren.
grafik
Übrigens finde ich es sehr angenehm, dass mAirlist zu den Anwendungen gehört die die Datenbank auch das machen lassen wozu sie da sind. Das habe ich leider auch schon anders erlebt, wo man dann zig Funktionen in die Anwendung hebt, die man eigentlich die Datenbank machen lassen könnte.

1 Like

(Hervorhebung im Zitat von mir)

Überraschung: Nein.
Torben und ich haben darüber gesprochen, und er hat das ganz intelligent programmiert:

Unabhängig davon, was du in den nächsten Tagen bereits geplant hast, hat das keinen Einfluss auf die nächste zu planende Stunde des laufenden Tages.
Torben hat das wie folgt kommentiert:

Beispiel: Du planst Montag 0-23 Uhr, dann wird der Scheduler für jeden Titel ermitteln, wann er bis einschließlich Sonntag 23 Uhr zuletzt eingeplant war. Was für Montag (oder Dienstag, Mittwoch, etc.) schon geplant war, wird ignoriert.

Einzige Ausnahme: Wenn der Dienstag bereits vorgeplant ist, kann es zu unerwarteten Überraschungen kommen. Da der Scheduler nicht “nach vorne schaut”, kann ein Titel am Montag um 23 Uhr natürlich gleich nochmal in der - vorgeplanten! - Stunde am Dienstag um 0 Uhr vorkommen.

Abgesehen davon kannst du z.B. zu Testzwecken erzeugte Playlisten wieder löschen oder überschreiben. Das beeinflusst die Planung an sich nicht, da er immer nur die Planungsdaten bis zur aktuell zu planenden Stunde einbezieht, nicht mehr.

Ungeachtet dessen empfehlen wir grundsätzlich, die Planung stets chronologisch ablaufen zu lassen.


Wie hat denn der vergangene Dienstag geklappt, gibt es schon erste Erkenntnisse (Logs, Cue-Sheets)?

Ich schätze ich habe den Fehler zum “Collation Problem” gefunden. Meistens ändere ich bei meinen Servern nur die Zeitzone, lasse aber die locales auf default.
Da ich den Datenabnkserver eh komplett neu aufsetzen wollte (neuer debian unterbau und neue PostgreSQL Version), bin ich das Thema jetzt angegangen und habe dieses mal gleich alle locales entsprechend gesetzt, dadurch sind auch alle PostgreSQL Werte per default gleich richtig. Es würde vermutlich auch reichen das in der postgresql.conf anzupassen, anders herum ist es aber schneller. In der Conf steht auch der entsprechende Hinweis, sinngemäß: Das wurde bei der Initialisierung so gesetzt, kann aber später jeder Zeit geändert werden.

Das könnte man im Wiki vielleicht mal ergänzen, auch wenn es eigentlich zur allgemeinen Serveradministration gehört. Es sind letztendlich nur 2 Befehle, bevor man anfängt.
sudo dpkg-reconfigure tzdata Choose your Timezone
sudo dpkg-reconfigure locales Choose your local charset (UTF8 based) and make it the server default charset

Führt dann am Ende zu diesem Ergebnis.

Danke, für die detaillierte Erklärung, @shorty.xs! Ich denke aber, das jetzt in unsere Doku aufzunehmen, würde wirklich etwas weit gehen.

Ich meinte nur diese beiden Zeilen, für die Doku, bzw. vorangestellt noch: If not set already…

Um das Off-Topic abzuschließen:
Ich habe heute die Datenbank auf mein neues Backend umgezogen. Das Clonen aus der Datenbank heraus hat zwar relativ lange geaduert pgsql to pgsql aber ist fehlerfrei durchgelaufen.

Alles im laufenden Betrieb.
Da ich die DB-ID beibehalten habe war das am Ende nur der Wechsel der IP Adresse.

Die Sortierumg der Interpreten passt nun.

2 Likes

Wenn der Typ des Backends (hier: PostgreSQL) beibehalten wird, ist es schneller und oft einfacher, dessen eingebauten Dump-/Restore-Tools zu nutzen, also pg_dump/pg_restore.

Die Clone-Funktion kopiert die Tabellen Zeile für Zeile einzeln. Das ist wirklich langsam, hat aber den Vorteil, dass man so von einem System in das andere konvertieren kann.

Ich hatte vorher versucht mit HeidiSQL die Daten zu schaufeln, was deutlich schneller lief aber zu Fehlermeldungen führte. Deshalb habe ich in diesem Fall pg_dump gar nicht erst versucht, weil da das debuggen ggf. noch aufwändiger gewesen wäre.
Ich hatte die (warscheinlich unbegründete) Befürchtung, dass ich mir da aufgrund des großen Versionswechsels von (ich meine PG9) auf die aktuelle die mit Debian Bullseye kommt und der geänderten Kodierung, weitere Probleme oder Datenkorruption einfange.

Langsam und über mAirlist direkt, war mir da der vertrauenswürdigere Weg. Ich muss ja nicht daneben sitzen und warten bis der Statusbalken voll läuft.

Naja, pg_dump erzeugt ja im einfachsten Fall auch nur eine Textdatei mit SQL-Befehlen, die dann auf der anderen Seite ausgeführt werden, um eine exakte Kopie der Datenbank wiederherzustellen.

Allerdings nutzt es im Regelfall COPY-Befehle (einen pro Tabelle), die tausende Zeilen gleichzeitig einfügen können und daher sehr viel effizienter sind als die einzelnen INSERTs von mAirList.