seit 2 Tagen (nach dem Sendestart, davor lief alles) haben wir ein Problem, das ich so noch nie mit mAirList hatte. Wir haben gerade keinen Hinweis, voran es liegen könnte, daher hoffe ich auf Eure Ideen:
Das komplette GUI friert ein. Alle Anzeigen halten an, man kann nichts mehr klicken, auch nicht das X, um das Anwendungsfenster zu schließen. Während dessen läuft der letzte Player im Hintergrund zuende.
mAirList.exe nimmt in der Situation 15 % CPU in Anspruch, die RAM-Nutzung steigt an. Irgendwas passiert also wohl noch
Warten bringt nix, es kommt kein “Application seems to be frozen”
Es hilft nur killen im Task-Manager
Nach Neustart von mAirList läuft wieder alles.
Die nahezu gleiche Konfiguration läuft auf einem anderen PC auch.
In den Protokolldateien finde ich absolut keinen Hinweis.
FRAGE: Gibt es sowas wie einen Debug-Modus von mAirList, mit Hilfe dessen wir dahinter kommen könnten, was in dem Moment passiert, in dem das Problem auftritt?
Wir haben den PC vor kurzem ausgetauscht und dabei - weil es schnell gehen musste - alle SSDs/HDDs geklont (also keine Neuinstallation, alles übernommen, nur Lizenzdaten erneuert). Scheint auch insgesamt gut zu funktionieren. Und in den ersten Tagen gab’s mit mAirList auch keine Probleme.
Würde mich freuen, wenn jemand einen Hinweis hätte, auf welcher Ebene da was schief läuft. Wir kommen gerade mit der Analyse nicht voran.
Festplatten und USB Anschlüsse gehen gern einmal in den Standby.
Dieser lässt sich aber deaktivieren.
Ein weiterer Ansatzpunkt wäre hier eventuell das Netzwerk.
Auch hier hatte ich es schon, das Netzwerkadapter in den Stromsparmodus verfallen sind.
Aber das sind alles recht pauschale Aussagen von mir, welche als mögliche Fehlerquelle in Frage kommen.
Lässt sich denn bei dir feststellen, ob das einfrieren an bestimmte Ereignisse gebunden ist, so daß der Fehler reproduzierbar ist?
Die Beobachtung mit den 15% Auslastung bringt an der Stelle leider auch nichts.
Soweit wie mir bekannt ist, läuft Mairlist immer auf einem Kern
Bei Prozessoren mit mehreren Kernen kann es deswegen nie zu einer 100% Auslastung kommen.
Bei 4 Kernen wären es also max 25% die hier erreicht werden können.
Bekommst du auch kein “Application seems to be frozen” wenn du in das Mairlist Fenster klickst?
Den Standby-Modus können wir noch mal checken, guter Punkt. Eigentlich sollte das deaktiviert sein, aber vielleicht ist da beim Migrieren was schiefgegangen.
Der Fehler lässt sich leider gar nicht reproduzieren. Mal tritt er auf, mal nicht. Mal während Benutzerinteraktion, mal während die Automation vor sich hinläuft.
Es scheint eine Häufung, während Benutzerinteraktion zu geben. Jedenfalls lief die Automation seit heute Mittag problemlos durch. In der Sendung zwischen 19 und 21 gab’s das Problem 4 Mal.
Das mit der Auslastung hatte ich genannt, weil ich in Erinnerung habe, dass bei anderen mAirList-Abstürzen (mit “Application seems to be frozen”) die Auslastung eher auf 0 geht - oder auch mal auf Vollauslastung. Ob in diesem Fall der eine Kern voll ausgelastet ist, muss ich noch mal überprüfen.
Ich bekomme die ein “Application seems to be frozen”. Klicken hilft nicht, warten hilft nicht. Man kann am Ende ausschließlich den Task killen.
Du kannst in der Konfiguration > Erweitert > Optionen einen Debug-Modus einschalten.
Du kannst die standardmäßige Wartezeit von 60 Sekunden herabsetzen.
Wir hatten mal einen ähnlichen Fall im Support. Da stellte sich heraus, dass im Hintergrund eine Reihe von Dateien von einem nicht mehr existenten Netzlaufwerk zu laden versucht wurde. Das kann mAirList nicht sofort erfassen, weil die Antwort von Windows auf sich warten lässt (es sucht intern erst mal vergeblich eine Zeit lang).
Das geht seit dem Umzug des Lizenzierungsservers nur noch mit Version 5.3.17, wenn ihr den integrierten Lizenz-Manager benutzen möchtet.
Der manuelle Download geht nach wie vor.
Habe den Debug-Modus eingeschaltet und den FreetTimeout. Lasse es so jetzt mal laufen. Morgen müsste ja irgendwann das Problem wieder auftreten, und dann schauen wir mal …
Deine Schilderung von den Dateien mit dem Netzlaufwerk sehe ich hier zwar nicht, weil sich die Laufwerke bei uns nicht geändert haben und noch alle da sind.
Aber wir beobachten noch ein anderes seltsames Phänomen. Ich schreibe es, weil es ja möglichweise doch zusammenhängt.
mAirList speichert Mitschnitte durch die Aircheck-Recorder auf die lokale Platte D: Wir nutzen seit längerem Resilio-Sync, um die Dateien auf ein Netzlaufwerk zu spiegeln.
Neuerdings (auch seit dem neuen PC?) beobachten wir, dass Resilio manche Mitschnitte nicht synchronisiert. Teilweise hilft es, wenn man die Datei öffnet und wieder schließt. Manchmal muss man sie umbenennen. Manchmal hilft das alles nicht.
Ist ähnlich schwer nachvollziehbar wie das andere Problem.
Ich habe überlegt, ob mAirList die Dateien vielleicht manchmal nicht richtig schließt - und dass ähnliches vielleicht im Rahmen dieses Einfrierens an anderer Stelle auch passiert. Ist aber nur Spekulation.
Vielleicht hilft für beide Probleme der Debug-Modus.
Wohin speichert mAirList die Debug-Informationen?
Ich verweise auf einen anderen Forenbeitrag von Torben:
Nachher weise ich Torben auf deinen Forenbeitrag hin. Wir sind im Support allerdings in größeren Projekten gebunden. Ich hoffe, er findet zwischendurch Zeit für dein Problem.
Nachtrag: Ich habe das Thema in den Bereich “mAirList 5.x” verschoben. Du hattest ja auf diese Version hingewiesen.
Wir können im Augenblick nicht sagen, ob es mit Version 6 so immer noch passieren würde, aber wir haben - neben dem großen Upgrade - mAirList im Laufe der Zeit ja auch stetig weiterentwickelt. Durchaus auch aufgrund solcher Fehlermeldungen.
Dennoch schauen wir uns das im Detail an.
Für mAirList 5.x gibt es keine neuen Updates mehr - es sei denn, es sind elementare Änderungen wie zuletzt die Installation des neuen Lizenzierungsservers und der daraus resultierenden Veröffentlichung von Version 5.3.17 am 4. September 2019.
Darf ich dich noch bitten, deine Lizenznummer (erneut?) in dein Forenprofil einzutragen? Wir sind auf eine neue Forenplattform umgezogen, dabei wurden einige Profileinträge leider nicht übernommen.
Vielen Dank.
Völlig richtig. Ich wollte es eigentlich auch unter mAirList 5.x veröffentlichen. Ist wohl einfach zu spät
Ich weiß, wir müssen uns dringend die Version 6 anschauen. Wir hatten in letzter Zeit zu viele andere Baustellen. Lizenznummer trage ich erneut ein.
Erschreckend, dass ich so lange hier im Forum nicht mehr aktiv war. Vieleicht kommt das wieder.
Versuch ansonsten mal, die ini-Dateien im config-Ordner wegzuverschieben und zu testen, ob es dann startet. Wenn ja, die inis nacheinander wieder rein, eine nach der anderen (oder päckchenweise - binäre Suche) und schauen, bei welcher es hakt.
Also an sich funktioniert ja alles seit Sonntag. Ich hatte viel mehr Probleme durch die Migration erwartet. Klonen der Festplatten inkl. des Betriebssystems und hinterher nur wo nötig die Lizenzdateien erneuern, ist ja nicht unbedingt vorgesehen. Uns lief aber die Zeit weg.
Erst Dienstagabend nach der ersten Live-Sendung im Automationsbetrieb kam es zum ersten Mal zu diesem Einfrieren.
Jetzt gerade läuft mAirList seit ca. 9 h in der Automation durch. Ich warte jetzt mal, bis der Fehler wieder auftritt. Sobald das passiert, werte ich die Debug-Daten aus und melde mich.
Um es ganz einfach zu sagen: Das Problem ist eine unbeabsichtigte Endlosschleife in einem Script. Diese wurde in Fällen ausgelöst, die wir vorher nicht getestet und somit übersehen hatten.
Etwas genauer: In einem Hintergrundscript, das OnExecuteCommand abarbeitet, haben wir mehrere Befehle definiert, die wir zerlegen, weil per Remote Parameter mitgegeben werden. Ein dummer Fehler führte dazu, dass beim Zerlegen des Befehls in bestimmten Fällen ein Befehl gebildet und ausgeführt wurde, der sich selbst ausführte und somit unendlich aufrief.
Wir kamen drauf, weil wir schließlich die Fernsteuerungskonsole beobachteten.
Es war also klar ein Fehler in unserem Script. Es hatte nichts mit dem Hardware-Wechsel zu tun, aber mit anderen Änderungen im Zusammspiel mit unserer Studio-Hardware.
Was mich aber wundert, ist, dass so eine Endlosschleife mAirList komplett lahmgelegt hat - und dass auch der Watchdog nichts davon gemerkt hat.
Ich habe das Verhalten mal durch einen “Absturz-Befehl” nachgestellt:
Wenn ich eine endlose Schleife in ein Script einbaue (wie z.B. i := 1; while i > 0 do begin i := 1; end;), dann legt das mAirList komplett lahm.
Ist das bekannt? Ist das in Version 6 auch noch so?
Klar, verstehe ich. Aber lässt sich so ein Thread evtl. so “deckeln”, dass dadurch eben nicht die anderen mAirList-Threads lahmgelegt werden? Alle anderen Prozesse waren unbeeindruckt.
Vielleicht habe ich da eine falsche Vorstellung von den Möglichkeiten der unterschiedlichen Threads. In meiner Vorstellung sollten die unterschiedlichen Threads gerade dafür sorgen, dass die anderen Threads nicht in Mitleidernschaft gezogen werden, wenn ein Thread durch die Decke geht.
Aber ob sich das realisieren lässt, dafür bist Du der Profi. Davon habe ich zu wenig Ahnung. Daher ist es - wie immer - als Anregung gemeint.
