seit vielen Jahren läuft mAirList hier absolut zuverlässig. Dem ist auch weiterhin so, jedoch plagt mich seit einigen Wochen ein neues, recht nerviges Problem, das ich mir nicht ganz erklären kann: Die GUI Ruckelt beim Titelwechsel (ab Start Next) kurzzeitig extrem bzw. friert sogar für einige Sekunden ein. Hörbar sind diese Ruckler glücklicherweise bisher nicht, jedoch macht es die Nutzung von mAirList im Assist Modus nahezu unmöglich. Seit etwa der gleichen Zeit besteht eine enorme Verzögerung beim Umschalten zwischen dem Automations- und dem Assistmodus (auch hier friert die GUI für einige Sekunden ein).
Kurz zum Setup:
Windows 10 Professional 1709
Intel Core i7-3770, 16 GB RAM (dedizierter Playout Rechner)
mAirList Professional Studio V6.3.14
Dante Virtual Soundcard (für WASAPI konfiguriert)
DHD RM3200D
Folgende Fehlerquellen wurden bereits ausgeschlossen:
Audioeinstellungen (testweise bei allen eingebundenen Playern auf “keine Wiedergabe” geändert, keine Änderung)
Datenbank (es spielt keine Rolle, ob die Datenbank eingebunden ist oder nicht. Es ist auch egal, ob die abgespielten Elemente aus der Datenbank stammen oder als Raw Files direkt in ML gezogen werden)
DHD beim Auto/Assist Lag (Fehler tritt auch beim Umschalten über die GUI per Maus auf, außerdem ist die Cartwall nicht betroffen und spielt ohne Verzögerung aus)
Windows Energiesparoptionen (wurde nie verändert, vorsorglich nochmal geprüft, nach wie vor “Höchstleistung” ohne Datenträgerstandby)
Ein Neustart sämtlicher involvierter Komponenten wurde durchgeführt
Das Problem trat plötzlich und ohne jegliche Änderung auf. Ich hatte daraufhin mAirList auf Version 6.3.14 aktualisiert, in der Hoffnung, die aktuelle Version würde Besserungen der Performance bringen (Changelog 6.3.13: “Improved GUI performance when working with very long playlists”).
Startet man mAirList neu, verschwindet der Fehler für einige Tage, manchmal bis zu eine Woche, und tritt dann plötzlich wieder auf. Ich habe das ruckelnde mAirList jetzt mal laufen lassen, in der Hoffnung, den Auslöser eingrenzen zu können. Bis zum erstmaligen Auftreten des Fehlers musste ML nur zum Einspielen von Updates (vielleicht einmal alle 3 Monate) neu gestartet werden.
Wo liegen denn die Audiodateien? Lokal auf dem PC oder auf einem Netzlaufwerk/ NAS? Gibt es einen Unteschied der File-Location zwischen Carts und Playlistenelementen?
Sind asynchrone Dateizugriffe aktiviert in mAirlist?
vielen Dank für die schnellen Rückmeldungen und Hinweise. Zu den Fragen:
Die Audiodateien liegen auf einem Netzlaufwerk, ich kann die Problematik aber auch mit lokalen Dateien reproduzieren.
Playlist- und Cartwall Files liegen am selben Ort
Asynchrone Dateizugriffe sind deaktiviert
Logging ist ausschließlich in Richtung Icecast Server aktiv, die Logging Einträge habe ich aber bereits testweise deaktiviert (leider ohne Besserung)
Ich habe den FreezeTimeout in der mAirList.ini mal auf 2 Sekunden gesetzt und würde ML gleich mal neu starten. Da der Fehler in der Regel erst nach einigen Tagen auftritt, habe ich vorher noch händisch versucht, einen Bug Report zum Zeitpunkt eines GUI Freezes zu erzeugen. Soll ich den schon mal an support@mairlist.com übermittlen?
Danke, ich habe asynchrone Dateizugriffe nun aktiviert und anschließend ML neu gestartet. Mal beobachten, wie es sich die Tage verhält. Sobald ein Bug Report erzeugt wird (FreezeTimeout=2, müsste reichen), schicke ich dann mal durch. Den händisch erzeugten Bug Report habe ich bei Bedarf auch noch hier, gerne einfach Bescheid sagen, wenn ich den mal rausschicken soll.
Was ist da eigentlich der Defaultwert, wenn ich heute ein frisches mAirlist aufsetze?
Gibt es eigentlich eine Übersicht der Defaultwerte, die sich im Laufe der Zeit mal verändert haben, weil man festgestellt hat, dass ein anderer Defaultwert, meistens besser funktioniert?
Sowas würde ich mir im Wiki wünschen, dass man da nicht durch die ganze Historie suchen muss.
Defaultwert bis Version X, neuer Defaultwert ab Version Y
Dann kann man da dran lang gehen und bei älteren Installationen gesammelt nachziehen.
Püha… riecht nach Fleißarbeit, wenn ich ab v5.3 aufwärts beginne (älter empfinde ich als wenig sinnhaft). Könnte ich sicher mal zusammenstellen, bin aber noch zwiegespalten.
Vielleicht nach Feierabend, nichts für die Arbeitszeit.
Ich sehe einen Vorteil darin, dass man durch das “durchschleppen” bestehender Konfigurationen über die Versionen gewisse Neuerungen überfährt.
Es gibt aber Changelogs und Release Information im Wiki, wenngleich nicht immer mit neuen Standards.
Mal sehen.
bisher ist das Problem noch nicht wieder aufgetreten. Ich warte mal noch die kommenden Tage, auch den wöchentlichen Import, ab und gebe dann nochmal Rückmeldung.
ein kurzes Follow-Up dazu: Leider tritt der Fehler inzwischen wieder auf. Die Uptime der mAirList-Instanz beträgt knapp über 8 Tage. Gestern Abend lief noch alles sauber, inzwischen ruckelt die GUI wieder bei jedem Titelwechsel. Auch die Auto/Assist Umschaltung hakt nun wieder. Ein Bugreport wird leider nicht erzeugt (der “this application seems to be frozen” Dialog erscheint nicht).
Gibt es weitere Möglichkeiten, der Ursache auf die Schliche zu kommen? Es scheint wirklich etwas zu sein, das nur im Moment des Titelwechsels sowie bei der Auto/Assist Umschaltung passiert. Gefühlt tritt die Problematik exakt in dem Moment auf, in dem die entsprechenden Log Einträge in das Systemprotokoll geschrieben werden.
Noch ein kurzer Nachtrag dazu: Ich habe das Systemprotokoll gerade testweise mal händisch geleert. Seitdem läuft alles wieder einwandfrei, sowohl der Titelwechsel, als auch die Auto/Assist Umschaltung. Kann es sein, dass das Systemprotokoll ab einer gewissen Größe Probleme macht? Ich habe mir gerade mal die Konfiguration angeschaut und gesehen, dass bei “Dateiname” nichts hinterlegt ist. Macht es Sinn, hier einen lokalen Default Pfad zu hinterlegen? Ich habe diesen Parameter ehrlich gesagt bisher nie angefasst. Wo wird der Log überhaupt per Default abgelegt?
z
Danke für die schnelle Rückmeldung. Das Timeout Intervall für den Freeze hatte ich bereits von 60 auf 2 Sekunden reduziert, in der Hoffnung, einen entsprechenden Bugreport im Moment eines Freezes zu erzeugen, leider vergeblich.
Seit dem händischen Leeren des Logfiles vorhin läuft nach wie vor alles einwandfrei, sogar ohne Neustart von ML, es scheint also tatsächlich mit dem Systemprotokoll zusammenzuhängen. Vielleicht würde also beispielsweise eine Funktion wie “lösche das Logfile alle X Tage” Abhilfe schaffen.
Wo legt mAirList das File denn ab (falls überhaupt), solange kein Dateipfad in der Konfiguration festgelegt ist? Im Zweifelsfall bastle ich ein kleines Batch Script und lasse das dann einmal pro Woche laufen und das Logfile löschen.
