DMXC 3.3.1: GUI stürzt im Langzeitbetrieb ab

Guten Abend...

der erste Punkt für die entsprechende Unterstützung sind in der Tat die Log-Dateien von allen Systemen, wo dieses Problem bis jetzt aufgetreten ist sowie im Idealfall auch die zugehörigen Projektdateien. Wenn daraus nichts direktes ersichtlich ist, müssen in der Tat "schwere Geschütze" aufgefahren werden.

Stefan

PS.: Ich habe den Titel des Threads mal um ein Schlüsselwort "Langzeitbetrieb" ergänzt, weil dieser Punkt eben entscheidend für dein Problem ist.

Hallo,

ok, also Logs sind nie verkehrt. Aber das klingt hier sehr nach Speicherleck. Diese sind leider nicht so einfach zu finden und kündigen sich normalerweise nicht in Logs oder so an. Daher ja, es wäre gut, diese auch zu haben. Da solche vermuteten Speicherlecks nicht so einfach zu finden sind, wäre es gut, wenn wir den Problembereich noch etwas eingrenzen könnten. Du sagst, dass die GUI zuverlässig abdampft, wenn der Audioanalyzer aktiv ist. Dazu hätte ich zwei Dinge, die gut wären, wenn du diese auch noch testest. Wie sieht der Betrieb des gleichen Setups aus, wenn der Audioanalyzer und auch sonst kein Plugin läuft? Und zusätzlich wäre es gut zu wissen, ob das Problem auch mit anderen GUI-Plugins auftritt? Hintergrund dieser Untersuchungen: Die Kombination aus beiden Untersuchungen lässt Schlüsse darauf zu, wo das Problem verortet ist (im AudioAnalyzer Plugin, in der Plugin-Schnittstelle von DMXControl 3 oder in DMXControl 3 selbst).

Viele Grüße
JP

Hi,

ich schreibe es mir mal auf, dass ich das in den Weihnachtsferien mal teste und schaue, ob ich es reproduziert bekomme, also so, dass ich sehe, wo genau das Speicherleck steckt. Bzw. ich werde das nochmal intern besprechen und dann schauen wir, wer das analysiert. Wie schon oben geschrieben sind solche Fehler fieser und nicht so einfach zu finden. Werde mich aber mal auf die Suche machen. Wie gesagt kannst du da leider gar nichts machen außer immer wieder mal DMXC neu zu starten. Ich melde mich, wenn ich Neuigkeiten habe.

Viele Grüße

JP

Sooo ich habe jetzt mal intern besprochen und da kam eine Frage auf, die du für uns testen könntest. Damit könnten wir dann den Fehler weiter eingrenzen und was aus nicht 100%ig herauskommt aus deinen Kommentaren: Du hattest gesagt, du hast auch mal ohne den Audio-Analyzer gearbeitet (T-W-Licht). War da der AudioAnalyzer nur deaktiviert oder war er auf diesem PC gar nicht installiert? Wenn du ihn nur deaktiviert hast, könntest du mal bitte den AudioAnalyzer aus DMXControl 3 entfernen (oder DMXControl 3 noch einmal in einen zweiten Ordner installieren und dort den AudioAnalyzer nicht mitinstallieren). Der Hintergrund ist: Die Plugins werden auch schon geladen, auch wenn der Haken nicht gesetzt ist. Sie werden nur eben nicht aktiviert. Wenn da schon bei der Initialisierungsroutine etwas zu dem Speicherleck führt, dann ist trotzdem der AudioAnalyzer schuld. Aber dann könnten wir das besser eingrenzen, wenn du das mal testen könntest

Viele Grüße

JP

Hey, kein Problem. Du musst den AudioAnalyzer komplett aus dem DMXControl 3 Ordner rauslöschen / verschieben. Dann findet DMXC den nicht mehr. Wenn du die Datei nur umbenennst, geht es trotzdem, weil DMXControl 3 beim Start den kompletten Ordner scannt.

Hallo Axel,

nachdem ich DMXControl 3.3.1 nun am vergangenen Wochenende selbst mal wieder etwas länger habe laufen lassen (bei mir waren es etwas über 50 Stunden), habe ich nun mal in deine Projekte geschaut. Dabei sind mir Dinge aufgefallen:

• Generell gefragt: hat es einen Grund, dass du viele der Geräte nicht über eine bzw. mehrere Cuelist steuerst, sondern dies direkt über den Programmer löst?
• Sehe ich das richtig, dass der Programmer in den Fensterlayouts durchweg geöffnet ist (selbst nur als Reiter im Hintergrund)?

Ich hänge mich gerade ein bisschen an dem Programmer auf, weil es hier auf Grund des verwendeten Frameworks zum Anzeigen der Inhalte schon oft Probleme bei der Performance gab - vor allem wenn dieser geöffnet ist. Wenn du dann auf Grund der von dir gewählten Programmierweise auch noch laufend Werte hineinschiebst bzw. veränderst, könnte dies ebenfalls mit eine Ursache sein. Wir sagten hier ja schon länger, dass die Aufgabe des Programmer vorrangig im Programmieren einer Show / eines Projekts liegt und weniger, mit dem Programmer auch eine Show zu fahren. Um während einer Live-Show trotzdem Werte live manipulieren zu können, wurden mit DMXControl 3.3.0 ja extra noch die Color- und Position Master ergänzt.

Dies mal meine Beobachtungen für den Moment. Ich werde nun im Anschluss das Projekt "T-W-Licht" für mich mal dahingehend ergänzen, dass ich es bei mir mit realen Geräten über den Tag mal laufen lassen kann.

Stefan

Quote from LightningBrothers

Ich hänge mich gerade ein bisschen an dem Programmer auf, weil es hier auf Grund des verwendeten Frameworks zum Anzeigen der Inhalte schon oft Probleme bei der Performance gab - vor allem wenn dieser geöffnet ist.

Ich habe mich nun mal weiter in deinem Projekt "T-W-Licht" orientiert. Also ich bleibe bei meiner Vermutung, dass die Instabilität in deinen beiden Projekten, aber insbesondere im Projekt "T-W-Licht" daher rührt, dass du hier mit dem Spektrum des Audio Analysers laufend Werte im Programmer aktualisierst und so eine Show aus dem Programmer fährst.

Da ich davon ausgehe, dass die Bedienweise über die beiden Softdesks bei dir etabliert ist, solltest du dir den "Unterbau" vornehmen und sämtliche Effekte vom Programmer unter Verwendung von Parameter- und Color-Mastern in Cuelists umziehen. Damit löst sich am Ende auch das Problem, dass du nicht "sauber" zwischen den verschiedenen Effekten umschalten kannst. Möglicherweise brauchst du dann auch nicht mehr zwischen "Workshop" und "Disco" trennen und hast wieder ein Projekt für alles. Wenn du hierzu noch Tipps brauchst, melde dich bitte - entweder in einem separaten Thread oder du hängst deine Fragen in bereits thematisch passenden Threads an.

Unabhängig davon würde ich mich aber noch über Antworten zu den beiden Fragen aus meinem vorangegangen Post freuen.

Quote from AxelF

Ist das nicht gut ? Das wusste ich nicht.

Es ist insbesondere auf Grund der Gesamtkonstellation "altes Framework für die Darstellung" + "Programmerfenster offen" + "viele (schnelle) Werteänderungen" (aktuell) nicht gut. Deswegen hängt die GUI auch aktuell mal, wenn man komplexere Szenen mit vielen Werten für unterschiedliche Geräte (-gruppen) in den Programmer lädt und das Programmer-Fenster offen ist. Inwieweit sich das bessert, wenn irgendwann der Programmer technisch erneuert wurde, lässt sich auch erst dann sagen. Bis dahin ist der Weg, eine komplette Liveshow über den Programmer zu fahren, keine gute Wahl.

Quote from AxelF

Der Audiosanalyser ist auf den beiden Systemen (T-W-Licht und WSL-Licht) deinstalliert.

Ich kann mir vorstellen, dass es in diesem Fall wirklich eher an dem Aufbau des Projekts liegt und weniger am Audio-Analyzer.

Quote from AxelF

Welche Logdatei hättest du gerne ?

Ich brauche in diesem Fall dafür keine Logs. Den ungünstigen Aufbau des Projekts habe ich da deswegen gesehen, weil ich mit dein Projekt in DMXC angesehen habe.

Ja... das ist in der Tat meine Vermutung, dass es durch die Nutzung des Programmers für die Show auch beim Workshop-Projekt nach den zwei bis drei Tagen zu dem Absturz kommt. Deswegen auch die Frage:

Quote from LightningBrothers

Sehe ich das richtig, dass der Programmer in den Fensterlayouts durchweg geöffnet ist (selbst nur als Reiter im Hintergrund)?

Soll umgekehrt heißen: was passiert, wenn du mal wirklich alle Fenster in der GUI schließt (inklusive der Steuerungsfenster) und nur die beiden Softdesks offen sind?

Aber schlussendlich wäre mein Ansatz eben, das Projekt umzubauen, dass der Programmer gar nicht mehr genutzt wird.

Quote from AxelF

Der Programmer ist normalerweise immer geschlossen.

Hast du darauf geachtet, dass dies beim Laden auch wirklich der Fall ist? Denn aktuell kannst du ja immer nur das zuletzt gespeicherte Fensterlayout laden und da war der Programmer bei mir mit offen - wohlgemerkt in dem Stand der Projekte, die du seiner Zeit hochgeladen hattest.