“Application frozen”, jede Viertelstunde einmal für 15-30 sek Sendeloch, dann läuft’s weiter. Woran kann das liegen?
Dieses Problem hatte ich definitiv früher nie. Erst seit Version 4.1.3 PE tritt es ständig auf.
An der Datenbank-Anbindung dieser Ausspielstation über VPN kann es eigentlich nicht liegen, da diese ja nur einmal stündlich gezogen wird, oder? Gibt es irgendwie die Möglichkeit die Postgres-DB zu syncen. Also lokale DB in sync mit Server-DB? Oder sollte ich den Grund eher woanders suchen?
Ich würde gerne einen Bugreport speichern, jedoch friert er wie gesagt immer nur einige Sekunden ein. Danach läuft’s weiter. Einen Totalabsturz gibt es in unregelmäßigen Abständen. Dann bleibt er komplett hängen und wiederholt ein Songsample (kurze Sequenz) in Dauerschleife. Dabei stürzt mairlist ab und muss neu gestartet werden.
Ich habe außerdem bemerkt, dass nicht alle gespielten Titel wie üblich im Papierkorb landen bzw. geloggt sind. Mal fehlen einige, mal nicht. Mal ist bei einigen nur ein “?” statt der tatsächlichen Startzeit notiert.
Ich bin ziemlich ratlos.
Update: Bugreport kommt gleich per E-Mail.
Der manuell aus dem Menü heraus erstellte Bugreport hilft hier wenig - ich brauche den Call Stack in dem Zustand, wo die GUI gerade nicht reagiert.
Öffne mal die mAirList.ini und trage im Abschnitt [Options] das folgende ein:
FreezeTimeout=5
Dann geht der “Application seems to be frozen”-Dialog nicht erst nach einer Minute sondern schon nach fünf Sekunden Nichtreagieren auf; das erhöht die Wahrscheinlichkeit, dass ihr es schafft, den Dialog abzufangen und den Bugreport zu erzeugen.
Auch mit dem verkürzten FreezeTimeout lässt sich leider keine Freeze-Meldung erzwingen.
Ich werde wohl mal weiter beobachten und versuchen ein Verhaltensmuster zu entdecken…
Ich vermute inzwischen, dass es mit Konfig zutun hat. In den Optionen waren Häkchen sowohl bei “StartNext als Liedende betrachten” als auch “Fade-Out-Punkt als Liedende betrachten” gesetzt. Möglicherweise kollidiert da was. Ich habe jetzt mal das Häkchen bei letzterem rausgenommen, da eigentlich hier alles auf den StartNext-Punkt als Trigger für’s nächste Element hinausläuft. Mal sehen, ob es was bringt.
Trotzdem dürfte ja bei einer solchen Kollision nicht gleich alles hängenbleiben, oder?
Update: Meine Idee mit dem Häkchen hat nichts gebracht.
Aber es ist zu beobachten, dass er immer nach Jingles/IDs (sehr kurzen Elementen) hängen bleibt, nicht nach Musiktiteln.
Interessant wäre wirklich die Frage, welche letzte funktionierende Version ihr im Einsatz hattet. Nur so lässt sich nachforschen, welche Änderung im Code für den Effekt verantwortlich sein könnte.
Das kann ich dir genau sagen: Version 4.0.3 build 1253.
Dazu kam halt vor Install der 4.1.3 hier noch der Umzug mit Anbindung über VPN.
Von daher ist es schwer rauszufinden, ob der Effekt nun eher mit der DB-Verbindung zu tun hat oder eben mit dem Update.
Das kann ich eben nicht nachvollziehen. Notfalls installiere ich eine DB-Kopie testweise lokal, um zu sehen, ob
es dann immer noch zu diesen Hängern kommt.
In einem deiner Bugreports konnte man erkennen, dass gerade der Hintergrundthread aktiv war, der den Playlist-Cache aktualisierte. Eigentlich passiert das im Hintergrund, es kann aber trotzdem mal sein, dass es den Rest des Systems beeinflusst, wenn es sehr lange dauert.
Meine Idee wäre testweise den Playlist-Cache abzuschalten bzw. das Intervall hochzusetzen und dann zu schauen, ob die Hänger dadurch weggehen bzw. weniger werden.
Gleich nach dem ersten Jingle hängt er wieder. mairlist ignoriert einfach den Startnext-Punkt (des Jingles) und läuft in die Minus-Zeit bevor er nach ca. 5 Sekunden Hänger mit dem nächsten Titel weitermacht.
Kann man das Problem dann so zusammenfassen, dass Start-Next-Punkte grundsätzlich ignoriert werden? Oder “hängt” da noch mehr? Und kannst du das mit diesen Jingles reproduzieren?
Er ignoriert die Startnext-Punkte teilweise bei Jingles, aber offenbar nicht immer. Bei Titeln ist es bisher nie passiert. Ich versuche weiter ein Muster zu erkennen.
Update: Der Fehler ist wahrscheinlich nicht reproduzierbar! D.h. wenn ich das gleiche Jingle nochmal manuell in die Playlist ziehe, dann klappt der Übergang einwandfrei. Kann es sein, dass Cue-Infos bei der über VPN gezogenen Playlist möglicherweise teilweise fehlen bzw. nicht übermittelt wurden?
Kann ich mir eigentlich nicht vorstellen. Du kannst ja mal sicherheitshalber die Playlist als .mlp speichern, nachdem sie geladen wurde, und im Texteditor schauen, ob alle Cuepunkte da sind.
Hast du eigentlich das Datei-Management bzw. die Optionen zum Vorpuffern im RAM eingeschaltet? Wenn ja, schalte das mal ab.
Außerdem solltest du auch nochmal den aktuellsten Build testen. Wir sind bei v4.1.4.1502. Ich erinnere mich an einen klitzekleinen Bug, der etwas damit zu tun haben könnte und inzwischen behoben wurde.
Playlist abgespeichert und angesehen… was auffällt, dass nicht alle Titel Startnext-Punkte haben… aber CueOut-Punkte sind immer da.
Aber das rührt daher, dass diese einfach nicht gesetzt wurden, da importiert. Die Jingles haben aber alle Startnext-Punkte.
Gibt es vielleicht Konfig-Kostellationen des Cue-Punkt-Handlings, die sich ausschließen oder nicht vertragen?
Hier ist aktuell nur ein Häkchen bei “Startnext-Punkt als Liedende betrachten”. Siehe Screenshot.
Datei-Management abschalten hat nichts gebracht. Auch hier zeigte sicher der Hänger gleich wieder nach dem ersten gespielten Jingle.
Aktuellster Build installiert. Auch damit keine Änderung.
Die beiden Optionen bezüglich Liedende beziehen sich nur auf die Darstellung (bis wohin mAirList runterzählen soll), für die Wiedergabe spielen sie keine Rolle.
Ich sehe zwei mögliche Ursachen:
Entweder ist bei der Verarbeitung der Start-Next-Punkte noch irgendwas kaputt; ich konnte aber nach mehrfacher Überprüfung nichts erkennen. Im Zweifel muss ich mal einen Debug-Build erstellen, der die Cuepunkte mitschreibt.
Oder aber es liegt doch irgendwie an der langsamen Datenbankverbindung. Hier könntest du zum Test mal die Verbindung direkt nach dem Laden der Playlist deaktivieren (einfach in der Systemsteuerung den Haken wegmachen) und schauen, ob es dann ohne Probleme geht.
Neueste Feststellung: Betroffen sind nicht nur kurze Elemente wie Jingles, sondern doch auch (seltener) Musiktitel.
Aber ich meine festzustellen, dass die Häufigkeit des Auftretens variiert. Mal passiert es jeden 3. Titel, mal nur einmal pro Stunde.
Und doch kommt es mir subjektiv so vor, als ob das Problem nach dem Update von 4.1.3 auf 4.1.4 nicht mehr ganz so oft auftritt.
Wann genau wird eigentlich die DB-Verbindung tatsächlich benötigt? Wirklich nur beim nachladen der Playlists?
Braucht er die nicht nach jedem Titel, wenn er diese in die History/Papierkorb schiebt? Denn hier gibt es ja auch Unregelmäßigkeiten. Mal fehlen Titel oder erscheinen erst ne Viertelstunde später im Papierkorb, mal stehen statt Zeiten nur “?” dort drin. Ist das normal?
