DMXC 3.3.0 RC5: Ständige Abstürze der GUI

Hallo!

Kannst du einmal die kompletten Log-Files sowie auch das Projekt zur Verfügung stellen, mit dem du die Problematik am ehesten reproduzieren kannst? Denn gerade wenn du hier ein Projekt hast, was das Einfrieren der GUI regelmäßig hervorruft, ist dieses wichtig.

Was dann auch nochmal gut zu wissen wäre: die Hardware-Spezifikation deiner PC. Magst du einmal aufschreiben, welche CPU, GPU etc. in den Rechnern verbaut sind?

Stefan

Quote from Bernd

mittlerweile eine Größe von 70MB.

Das hier ist genau das Problem. Und DMXControl 3 sagt dir das auch tatsächlich, nämlich hier, ganz am Anfang der von dir eingefügten Fehlermeldung:

Quote from Bernd

10:25:31 ERROR GoboAffinityClass - Exception when loading Gobo ICON-001558.png: Out of memory.

System.OutOfMemoryException: Out of memory.

Das heißt, DMXControl 3 kann nicht mehr mehr Speicher allozieren / adressieren. Und das folgende ist jetzt entscheidend: Bis zu diesem Zeitpunkt war der Zugriff auf den von DMXContol 3 gemanagten Speicher konsistent. Alle Operationen um Dinge in Objekten zu speichern oder zu laden waren innerhalb der Bereiche der Objekte und alles war sauber organisiert. Das ist nun nicht mehr der Fall! Jetzt kann ALLES passieren und niemand, kann voraussagen, was jetzt passiert. Denn der von DMXControl 3 verwaltete Speicher ist jetzt in einem inkonsistenten Zustand, in dem Teile geschrieben wurden, Teile nicht. Keiner kann dir sagen, welcher Teil geschrieben wurde, bevor das passiert ist und jedes nun folgende Schreiben in den Speicher, was DMXControl 3 übrigens häufiger macht (z.B. bei jedem Empfang von Nachrichten) kann mehr halbe Objekte produzieren. Das ist beispielsweise der Grund für alle Punkte, die unter "Der Absturz äußert sich dann durch:" aufgelistet sind. Nun ist DMXControl 3 faktisch nicht mehr lauffähig und MUSS neugestartet werden. Wir können keinerlei Garantie geben, was ab dem Moment der Out of Memory Exception innerhalb von DMXControl 3 passiert und das werden wir auch nicht! Ab da ist der Speicher faktisch ein Trümmerhaufen!

Das erst einmal zu dem "Was". Nun zu dem "Warum": Jetzt könnte man ja auf die Idee kommen: "Häää, wieso geht DMXControl 3 der Speicher aus? Ich habe doch 16, 32 oder sogar 64GB verbaut und der ist immer total leer, wenn das in DMXControl 3 passiert.". Leider ist DMXControl 3 oder genauer gesagt sind zwei der drei Komponenten von DMXControl 3 noch 32bit Programme. Sie können also maximal mit 32bit Adressen umgehen. Dies gilt auch für Speicheradressen. Durch andere weitere limitierende Faktoren können die verschiedenen Komponenten von DMXControl 3 dadurch in der Praxis etwa 1,4 - 1,8GB an Arbeitsspeicher adressieren, bevor ihnen der Speicher aus geht. Dieses Problem kann man umgehen, wenn man eine 64bit Applikation hat. Diese kann viel mehr Speicher adressieren (16 Exabytes, was etwa 16 Mio. Terabytes entspricht) und wird auf absehbare Zeit keine solchen Speicherprobleme mehr haben. Aber dafür müssen auch alle Dinge in DMXControl 3 64bit-kompatibel sein, was aktuell nicht gegeben ist. Wir arbeiten zwar daran, DMXControl 3 zu 64bit-Applikationen zu machen. Das braucht aber noch etwas Zeit, bis wir das geschafft haben.

Was kannst du nun dagegen tun? Gegen das eigentliche Problem (das DMXControl 3 aus 32bit Anwendungen besteht) kannst du nichts machen. Das müssen wir beheben. Das einzige, was du aktuell machen kannst und das dürftest du ungern hören: Downsizing. Dein Projekt ist schlicht zu groß sprich es müssen zu viele Dinge daraus in DMXControl 3 nach dem Laden verwaltet werden. Du musst also aktuell dein eines Projekt in mehrere aufteilen, damit das funktioniert. Das gilt solange, bis wir den 64bit-Support für den Kernel und die GUI fertig haben. Für das Erwartungsmanagement: Das dürfte noch ein paar Jahre dauern. Grund ist da vor allem in der GUI, dass wir mehrere große Fenster austauschen müssen (Stage View, Programmer, Input Assignment und die Netzwerkansicht). Das ist nicht so einfach und der Umfang ist groß. Wenn das geschehen ist, können wir XNA rausschmeißen, was aktuell der Blocker für eine 64bit-GUI ist. Im Kernel sind es die Interface Plugins. Da müssen wir uns noch Möglichkeiten anschauen.

Ich hoffe, dieser umfangreiche Post hat dir geholfen, das Problem zu verstehen und warum dies hier nichts ist, was direkt an DMXControl 3 selbst liegt. Denn es tritt hier kein Bug auf sondern liegt einfach am zu großen Projekt.

Viele Grüße

JP

Vorne weg: Dies hier ist jetzt nur für diesen spezifischen Fall hier gedacht und soll nicht als allgemeine Anleitung für solche Fälle verstanden werden. Bevor du das jetzt so kurz vor der Aufführung auseinander reißt: Zu dem Speicherverbrauch trägt alles mögliche bei. Dazu gehören auch Gobos und Gerätebilder. Schau mal, ob es in deinem Fall schon hillft, wenn du die Gobos und Gerätebilder aus dem LibDevices Ordner im DMXControl 3 Verzeichnis raus nimmst und temporär wo anders hinverschiebst, deren Geräte du nicht hast. Dabei triggerst du du dann auch die Gobo-Korrelation, die deutlich kleiner ausfallen sollte, weil du ja nur noch recht wenig Gobos hast. Das könnte wie gesagt für deinen speziellen Fall jetzt helfen, ohne das du das Projekt zerlegen musst.

Zumindest was die Bilder, Gobos und die Gobo-Affinity angeht, werden die immer geladen, damit die Gobos generell verwendet werden können und die Affinity generell funktioniert.

Ich hätte gern mal das project, da sind noch andere interessante fehlermeldungen drinne

Quote from Bernd

Eine Version des Projektes hat (wegen der enthaltenen Audiofiles) mittlerweile eine Größe von 70MB. Das ist zu groß um es hier ins Forum zu laden. Gibt es eine andere Möglichkeit das Projekt auszutauschen?

Schaue doch mal, ob du das Projekt über den Bugtracker als registrierter Nutzer einem neuen Ticket anhängen kannst - sofern der Punkt mit dem Austausch noch weiterhin ungeklärt ist.

Danke für das zur Verfügung stellen des Projekts. Ich habe es mir nun auch mal angesehen und konnte das von dir beschriebene Verhalten recht schnell nachvollziehen - die GUI ist bei mir auch abgestürzt, nachdem ich ein paar Audiodateien wiedergegeben habe und dann mal in eine deiner Timecode-Shows schauen sollte.

Wie es passiert, geht genau in die Richtung, wie JPK bereits sagte: es ist offenbar zu viel im Projekt und zwar neben den Gobos eben die zahlreichen Audiodateien. Letztere fluten zum Beispiel die GUI beim Anschauen einer Timecode-Show mit vielen Daten, weswegen der entsprechende Teil am Ende nicht mehr genügend Speicher erhalten kann und in die besagte "Out of Memory Exception" läuft. Diese Meldung taucht in verschiedenster Weise kurz vor dem finalen Absturz der GUI in den Logdateien auf. Bei mir finde ich an der Stelle unter anderem solche Meldungen in den Logs, denen aber dann noch welche folgen.

2025-01-14 20:03:16,033 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
<log4net.Error>Exception rendering object type [System.Reflection.TargetInvocationException]<stackTrace>System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.String.Concat(String str0, String str1, String str2)
   bei System.Exception.ToString(Boolean needFileLineInfo, Boolean needMessage)
   bei System.Exception.ToString()
   bei log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer)
   bei log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)</stackTrace></log4net.Error>
2025-01-14 20:03:17,233 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.Windows.Data.BindingExpression.ChangeWorkerSources(WeakDependencySource[] newWorkerSources, Int32 n)
   bei System.Windows.Data.BindingExpression.AttachToContext(AttachAttempt attempt)
   bei System.Windows.Data.BindingExpression.MS.Internal.Data.IDataBindEngineClient.AttachToContext(Boolean lastChance)
   bei MS.Internal.Data.DataBindEngine.Task.Run(Boolean lastChance)
   bei MS.Internal.Data.DataBindEngine.Run(Object arg)
   bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
2025-01-14 20:03:17,838 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
<log4net.Error>Exception rendering object type [System.OutOfMemoryException]<stackTrace>System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.Text.StringBuilder.ToString()
   bei System.Diagnostics.StackTrace.ToString(TraceFormat traceFormat)
   bei System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   bei System.Exception.GetStackTrace(Boolean needFileInfo)
   bei System.Exception.ToString(Boolean needFileLineInfo, Boolean needMessage)
   bei System.Exception.ToString()
   bei log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer)
   bei log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)</stackTrace></log4net.Error>

Aber gerade im Hinblick auf die zahlreichen Audiodateien in deinem Projekt, kommt bei mir folgende Frage auf: Wie viele von den Audiodateien hast du hier eigentlich nur unter dem Gesichtspunkt hinzugefügt, um nur ein System bedienen zu müssen? Ein entsprechender Ansatz wäre nämlich hier, dass nur die Audiodateien wirklich im Projekt verbleiben, wo es eine direkte Verwendung in einer Timecode-Show gibt. Alle anderen Audiodateien spielst du über eine separate Software ab.

Quote from Bernd

Das stimmt schon. So ein bisschen missbrauche ich da DMX-Control auch etwas

Hehe... grundsätzlich ist das auch nicht verboten... ich persönlich arbeite teilweise auch nach dem Motto: solange etwas nicht explizit unterbunden wird, muss es auch funktionieren - selbst wenn es am Ende möglicherweise in einer solchen Konstellation nie explizit angedacht war. Durch diesen Ansatz bin ich manchmal aber auch schon anderweitig an verschiedene Grenzen gestoßen.

Von daher ist dein Ansatz für mich auch absolut nachvollziehbar, wenn du dich alleine um noch zusätzliche Sachen kümmern musst und nicht genügend Hände zur Verfügung hast.

Quote from Bernd

Daher werde ich (wie von JPK vorgeschlagen) das Projekt jetzt einfach mal in 2 Teilprojekte teilen (z.B. vor und nach der Pause) und die entsprechenden Timecodeshows und zugehörige Audiofiles entfernen. So müssten sich in den Teilprojekten die Files in etwa halbieren.

Diesen Vorschlag hatte ich überlesen - aber der läuft ebenfalls am Ende ja auch auf das hinaus, was an dieser Stelle wichtig ist: die Größe des Projekts reduzieren.

Quote from Bernd

Für die Zukunft muss ich mal schauen, wie ich neue Projekte hinsichtlich Audio-Files gestallte. Ich hatte einfach im Vorfeld nicht erwartet, das 90MByte mp3s ein Problem darstellen könnten.

Wir sind hier beim Timecode-Player in DMXControl 3.3 (logischerweise) in der initialen Fassung unterwegs, wo es definitiv mit den kommenden Versionen entsprechende Optimierungen am Timecode-Player selbst, aber natürlich auch insgesamt geben wird. Dass der Timecode-Player aktuell nicht unendlich lange Audiodateien unterstützt, war uns durchaus in Teilen bewusst - es hatte sich aber nie so richtig die Gelegenheit ergeben, die (aktuellen) Grenzen final auszuloten. Mein Projekt beispielsweise, welches ich bei unseren Jahrestreffen nutzte, umfasst fünf Timecode-Shows. Allerdings war hier drumherum nicht so viel los wie bei dir, sodass es bei mir nicht zu den Abstürzen kam.

Quote from Bernd

Übrigens habe ich in den letzten Jahren mit der V_2.12 einige Musical-Nummern gefahren.

Du musst im Vergleich zu DMXC 3.3.0 im Hinterkopf haben, dass der Timecode-Player in DMXC 3.3.0 ein vielfaches mehr kann als der in DMXC 2. Das fängt eben allein schon mit der FFT-Analyse an, die beim Programmieren so aussagekräftiger ist als eine einfache Wave-Form.

Quote from Bernd

Kurze Frage noch: Kann es sein, dass von jedem File beim Laden des Projektes eine FFT und Waveform erstellt wird, auch wenn das File gar nicht in einer Timcodeshow eingebunden ist?

Wenn ich die Logs noch richtig im Kopf habe, wird die FFT erst generiert, wenn die entsprechende Timecode-Show im Timecode-Player angezeigt werden soll - das war ja bei mir auch der Zeitpunkt, wo bei mir die GUI ausstieg.

Quote from LightningBrothers

Wenn ich die Logs noch richtig im Kopf habe, wird die FFT erst generiert, wenn die entsprechende Timecode-Show im Timecode-Player angezeigt werden soll - das war ja bei mir auch der Zeitpunkt, wo bei mir die GUI ausstieg.

Nein, tatsächlich werden die FFTs generiert, wenn eine Audiodatei in DMXControl 3 geladen wird. Das ist tatsächlich unabhängig davon, ob sie in einer Timecode-Show verwendet wird oder nicht.

Moin, also, das mit den FFT-Analysen der Audiofiles wird mit dem x64 umbau warscheinlich kein problem mehr sein.

Das eigentliche Problem ist aber weniger die Analyse, als das UI-Framework WPF.

Dieses ist nicht in der Lage Bilder/Zexturen die einmal geladen wurden zu entladen.

Heist das der Speicherverbrauch steigt mit jeder weiteren Audiofile das in einer TimecodeShow angezeigt wurde(also ab dem moment wo es sichtbar im Fenster war)

Das wird aber auch mit x64 weit weit nach hinten verschoben

Ich hab dein Project mal in der Entwicklungsumgebung geladen,
Da sind fehler in ein paar DDFs, die es mir nicht erlauben das project zu öffnen

Kann man evtl. die Möglichkeit schaffen, dass eine Audiodatei direkt über nen executor gesteuert werden kann ohne Teil einer Timecode Show zu sein? Also quasi nen simpler Audioplayer? Für den Anwendungsfall das man keine Lichtshow zu den Audios benötigt und nur eine simple Möglichkeit Sounds usw. abzuspielen...

Gruße

Nutzer99

Quote from nutzer99

Kann man evtl. die Möglichkeit schaffen, dass eine Audiodatei direkt über nen executor gesteuert werden kann ohne Teil einer Timecode Show zu sein?

Hier in diesem Fall wurde es über das Sound-File-Node in Verbindung mit Makros gelöst. Aber im Projekt sind halt darüber hinaus noch eine ganze Reihe an Timecode-Shows in Verwendung.