Bugtracker DMXControl 3

Die Anwendung startet nicht mit Meldung in der Ereignisanzeige von Windows:

System.IO.FileNotFoundException: Could not load file or assembly 'CommunityToolkit.Mvvm, Version=8.4.0.0, Culture=neutral, PublicKeyToken=4aff67a105548ee2'. Das System kann die angegebene Datei nicht finden.
File name: 'CommunityToolkit.Mvvm, Version=8.4.0.0, Culture=neutral, PublicKeyToken=4aff67a105548ee2'

Der Test erfolgte am 30.10.2025.

Ticket wurde nach Rücksprache von @JPK nun nochmal hierher übernommen und dient vornehmlich als Reminder.

Die Anwendung startet nicht mit folgender Meldung im Log.

19:13:00 WARN  KernelRunManager - Missing ASM: Could not load file or assembly 'Antlr4.Runtime.Standard, Version=4.13.1.0, Culture=neutral, PublicKeyToken=e78b2c5abd1fcb3f'. Das System kann die angegebene Datei nicht finden.

Der Test erfolgte am 30.10.2025.

Ticket wurde nach Rücksprache von @JPK nun nochmal hierher übernommen und dient vornehmlich als Reminder.

Wenn das Ausgabeplugin für Art-Net 4 final ausgeliefert wird, musst der Installer im Installationsverzeichnis nach der alten Version suchen und die relevanten Dateien automatisch entfernen.

Ich nutze auf zwei Laptops die Art-Net 4 Ausgabe. In beiden Laptops habe ich die gleiche Art-Net-Konfiguration, um zwischen beiden Laptops teilweise oder auch vollständig wechseln zu können.

Wenn ich die Art-Net- / DMX-Ausgabe an den drei möglichen Stellen einzeln oder auch an allen drei Stellen komplett ausschalte, wird die Art-Net-Ausgabe nict komplett abgeschaltet. Dies mündet folglich in Störungen auf dem DMX-Bus, wenn ein anderer Laptop den Port des Art-Net-Nodes “übernehmen” soll. Die Lösung war hier das Treffen der Netzwerkverbindung zu den Art-Net-Nodes.

Mit der alten Art-Net-Ausgabe (in DMXControl 3.3.1) konnte ich den Wechsel noch ohne Probleme durchführen und eben auch die Art-Net-Ausgabe vollständig abschalten.

Geräte wie Tilt-Bars oder ähnliche - wo also nur eine von zwei Bewegungsachsen vorhanden sind - können vom Position Control aktuell nicht angesteuert werden.

Der Tooltip für den Button “Mitte der Punkte für Schieberegler” fällt größer aus als die anderen Tooltip im Position Control.

Ich gebe in die Kommandozeile (Commandline) folgenden Befehl ein:

select executorpage 2 item 6

Die Kommandozeile führt den Teil “select executorpage 2” zwar aus, der Teil “item 6” ist nicht implementiert und liefert kein Ergebnis. Der Befehl wird aber in Gänze mit grün als erfolgreich ausgeführt gekennzeichnet.

Analog zur globalen Highlight-Funktion soll die Highlight-Funktion im Position Mapping standardmäßig ebenfalls aus sein.

Es braucht einen automatischen Zeilenumbruch für “große” Befehle und / oder Kommentare.

Im Masterfenster werden die Titel / Displays nur noch in Mindestbreite angezeigt und füllen nicht mehr die Breite für einen Master aus.

Das Setzen der Reihenfolge für eine Device Group ist im Project Explorer ausschließlich über einen Doppelklick möglich. Im Kontextmenü zur Device Group fehlt ein entsprechender Eintrag mit der Beschreibung “Set Order of Devices” (siehe Bild 1). Damit ist die Funktion für die Device Group aktuell noch eine versteckte Programmfunktion.

Bei der Cuelist Group gibt es dagegen richtigerweise einen entsprechenden Eintrag im Kontextmenü zur Cuelist Group (siehe Bild 2).

Die Werte für Fade Factor und Speed Factor einer Cuelist umfassen bekanntermaßen einen Wertebereich von 0% bis 1000% (also 0 bis 10). Dies müsste der Cuelist Group Executor an dieser Stelle eigentlich auch unterstützen.

Vom Workflow ist es (zumindest für mich) einfacher, einen Effekt mit einer geringeren Geschwindigkeit zu programmieren und diesen dann auf Wunsch zu beschleunigen als immer von der maximalen Geschwindigkeit auszugehen (Stichwort Headroom).

Unter diesem Gesichtspunkt wurde bereits das Ticket  FS#4325  verfasst, dass sich hier aber vorrangig auf eine funktionelle Erweiterung des Cuelist Group Nodes im Input Assignment bezieht.

Ich lege ein neues Art-Net-Interface an oder aktiviere ein ggf. vorhandenes (wieder). In beiden Fällen erscheint im Kernel nach einigen Aktionen in der Stage View die folgende Fehlermeldung:

19:55:34 FATAL MainProcessRunable - Main Runnable seams stuck in an endless loop! You might have to restart DMXC... Please report this!

Sobald diese Fehlermeldung erscheint, kann ich in der GUI war Geräte in der Stage View auswählen. Setze ich aber die Farbe auf einer Gerätegruppe, werden diese Werte nicht mehr von den einzelnen Geräten wiedergegeben. Das Herunterfahren des Kernels klappt dann auch nicht mehr, da dieser keine Kommandos mehr entgegen nimmt.

Die beigefügten Logs zeigen den Ablauf:

1. DMXC 3.3.0 RC4 starten ohne zuvor konfigurierte DMX-Interfaces
2. Beliebiges Projekt laden
3. Art-Net-Interfaces einrichten
4. Ein paar einfache Aktionen in der Stage View
5. Auftauchen des Fehlers
6. Schließen der GUI und manuelles Anstoßen des Beenden des Umbras
7. Hartes Schließen des Kernels

Ich habe an einem Projekt zuletzt viel im Input Assignment gearbeitet und wunderte mich dann, dass ein Button eines Softdesks nicht mehr funktionierte. Der Kernel sagte dann folgendes:

22:15:27 WARN  InputManager - Following Graphs are orphaned and will be removed:
S1-510-3121
S1-510-0901
S1-210-0901
S1-211-3121

Hierzu habe ich die Erwartungshalten, dass erstmal nicht grundsätzlich angenommen wird, dass verwaiste Graphen entfernt werden können. Vielmehr bedarf es hier einer Info, wie hiermit umgegangen werden soll.

Ob sich dieses Verhalten mit dem Projekt, an dem ich gerade arbeite, reproduzieren lässt, muss ich später klären und dann Logfiles und Projekt beifügen.

Ich habe gerade meine verschiedenen Timecode-Shows umbenannt und dabei das Zeichen “|” verwendet. Der Name lautete “Intro 1 | DMXC-Video-Intro“.

Wird das Projekt gespeichert, führt dies zu folgender Fehlermeldung im Kernel:

12:25:57 WARN  ResourceManager - Unable to save Resource TimecodeShows\Intro 1 | DMXC-Video-Intro_9065fe68-5aa6-49c3-9513-f03fe6eb6689.xml of Type Project
System.ArgumentNullException: Value cannot be null. (Parameter 'filename')
   at org.dmxc.lumos.Kernel.Resource.FileMetadataCache`1.Remove(String filename) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\FileMetadataCache.cs:line 79
   at org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:line 487
   at org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:line 222
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.SaveResourceAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 768

Sobald ich dieses Sonderzeichen entferne und den Namen der Show zum Beispiel in “Intro 1 (DMXC-Video-Intro)” ändere”, kann das Projekt vollständig und ohne weitere bzw. wiederkehrende Fehlermeldung gespeichert werden.

Abschließend sei bemerkt, dass unter anderem das Zeichen “|” sonst soweit im Projekt genutzt werden kann, wie zum Beispiel im Namen von Cuelists.

In einem noch nicht näher bekannten Gesamtumfeld funktioniert die Merge-Funktion nicht zuverlässig, woraufhin die GUI sogar in Teilen abstürzt.

Genauere Details inklusive Log-Dateien kann Joseph (@nutzer99) liefern, da es bei ihm im Zuge der Programmierung seiner Show mehrfach aufgetreten ist. Ich möchte hiermit nur einmal das Problem grundlegend dokumentieren.

Ich habe an zwei PCs / Laptops unabhängig voneinander ein Nodle U1 sowie Nodle R4S betrieben wollen, auf dem Windows 11 in der Version 22H2 bzw. 23H2 installiert ist. Das Interface wird vom Kernel, der GUI und auch vom USB-Energy-Fixer richtig mit Seriennummer erkannt. Allerdings lässt es sich nicht aktivieren. Es verbleibt im Stand-By und die LED leuchtet weiter gelb.

Unter Windows 10 besteht diese Problematik nicht. Dort laufen meine Nodle R4S einwandfrei.

Die Logdateien reiche ich noch nach. Ich brauche hier aber auch unabhängig davon noch eine weitere Bestätigung. Das Ticket dient auch erstmal der Vorab-Doku.

Waren die DMX-Interfaces eine Zeit lang aktiv und werden dann über den Main-Switch abgeschaltet, meldet der Kernel wiederkehrend folgende Exception. Es ändert daran auch nichts, dass ich die DMX-Interfaces über den Main-Switch wieder einschalte.

21:41:15 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:18 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:20 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833
21:41:23 ERROR ArtNetFactory -
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 667
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 833

Ob es einen Zusammenhang zum Ticket  FS#5326  gibt, vermag ich nicht zu beurteilen. Deswegen habe ich dieses separate Ticket angelegt. Im Anhang finden sich die Logdateien, woraus der Zeitraum hervorgeht, wo ich den Main-Switch betätigt habe. Die Logs enthalten auch die DMX-Interface-Konfiguration.

Beim Konsolenfenster des Umbras ist das X zum Schließen des Fensters “freigegeben”, sodass ich darüber den Umbra “hart” beenden kann. Beim Kernel ist dies nicht möglich, da hier das X deaktiviert ist.

Es wäre daher gut, wenn man den Umbra wie bereits den Kernel nicht über X beenden kann.

Ich habe mir gerade einen Graphen gebaut, wo ich mit sechs-stelligen Zahlen arbeite und diese durch verschiedene Nodes schiebe.

Gebe ich eine solche Zahl zum Beispiel in den Binary Switcher als Wert für On bzw. Off oder in den Input Selector ein und bestätige diese Eingabe direkt mit Enter, wird die Zahl direkt in einen RGB-Wert konvertiert. Offenbar geht DMXC3 hier davon aus, dass es sich um einen HEX-Farbwert handelt.

Für mich ist das so dann nun zwar nachvollziehbar, dass es diese Assoziation gibt. Allerdings war das nicht meine Erwartungshaltung. Daher wäre meine Bitte, diesen Punkt einmal entsprechend zu durchdenken.

Ich habe auf einem PC bereits eine DMXC3.3-Instanz laufen. Dann starte ich auf einem zweiten PC eine weitere komplette Instanz von DMXC 3.3.0. Beide PCs befinden sich aber im gleichen Netzwerk. Hier beschwert sich der Kernel vom PC2, dass er sich nicht mit dem Umbra des PC1 verbinden kann - und in der Situation auch gar nicht soll. Die ersten Zeilen des Logs sehen wie folgt aus:

2024-04-04 23:08:38,105 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra DefaultUnknownServerName @ 192.168.21.31...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:line 688

Dieser Fehler ist mir bewusst erst mit dem RC2 unter die Finger gekommen. Grundsätzlich stört es den Betrieb nicht, aber der füllt das Log-File des Kernels.

Benenne ich eine Timecode-Show um, verbleibt die zugehörige XML-Datei mit dem alten Namen weiter in der Projektdatei. Diese wird auch beim erneuten Laden des Projekts eingelesen und dann beim nächsten Speichern wieder in der Projektdatei ablegt.

Der PWM static Effekt reagiert nicht mehr auf die Position des zugeordneten Parameter-Masters. Vielmehr wird der Effekt mit einer nicht weiter beeinflussbaren Geschwindigkeit kontinuierlich wiedergegeben - unabhängig des Werts des Parameter-Masters.

Hierzu im beigefügten Projekt die Cuelist ausführen und versuchen, den Effekt über den Parameter-Master 1 zu beeinflussen. Auch die Log-Dateien habe ich angehangen.

Wie es ausschaut, scheint sich dieser Fehler erst in einer der letzten Versionen eingeschlichen zu haben. Im RC1 existiert das Problem aber bereits.

Deaktiviere ich die DMX-Interfaces über den Main-Switch, fliegt im Kernel die folgende Exception

20:54:46 ERROR DMXInterfaceBag - Error setting interface Serial: ArtNet, Model: Art-Net, Vendor: Artistic License enabled state to False:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at System.Collections.Generic.List`1.Remove(T item)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.RemovePort(ArtNetInterface port) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 147
   at org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnDisable() in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNet.cs:line 150
   at DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value)
   at DMXInterfaceMgmtLIB.DMXInterfaceBag.SetEnabledInternal(Boolean target, Boolean byHeartbeatRestart, Boolean byMainSwitch) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\DMXInterfaceBag.cs:line 267

Bei der Wiedergabe einer Timecode-Show kommt es mehr oder weniger regelmäßig unregelmäßig zu einem Knacken im Audio / Ton. Teilweise stockt die Wiedergabe des Tons kurzzeitig.

Ticket wurde zwecks Dokumentation und zum Nachvollziehen der Testergebnisse nachträglich erstellt.

Die Message-Box muss an folgenden Stellen von ihrem Verhalten her angepasst werden. Der in eckiger Klammer gesetzte Eintrag ist derjenige, der standardmäßig vorbelegt sein soll

• Ordner (im Project Explorer allgemein) löschen: Ja / [Nein] (statt nur OK)
• Gerät löschen: Ja / [Nein] (statt nur OK)
• Cuelist löschen: Ja / [Nein] (statt nur OK)
• Cuelist Group löschen: Ja / [Nein] (statt nur OK)
• Datei löschen: Ja / [Nein] (statt nur OK)
• Item List löschen: Ja / [Nein] (statt nur OK)
• Zuordnung zu Executor löschen: Ja / [Nein] (statt nur OK)
• Stage View löschen: Ja / [Nein] (statt nur OK)
• Connectionset löschen: Ja / [Nein] (statt nur OK)
• Bank im Input Assignment löschen: Ja / [Nein] (statt nur OK)

Wie zu erkennen, ist bei den meisten Abfragen, die ein Löschen initiieren, standardmäßig das Schema “OK oder Dialog schließen zum Abbrechen” hinterlegt statt dem besseren Verhalten (auch bezogen auf die Fragestellung) “Ja / Nein”.

Hat sich aus irgendeinem der Kernel aufgehangen oder ich schließe ihn manuell, will dieser noch versuchen das Projekt zu speichern. Der Speichervorgang schlägt allerdings fehl und die betreffende Projekt-Version ist leer. Die zugehörige Datei ist 0 KB groß. Das sieht im Kernel-Log dann wie folgt aus:

2024-07-17 20:39:53,000 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker+TickerParallelBag - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2024-07-17 20:39:53,034 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Scene.SceneFadeTicker - Deregistriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2024-07-17 21:15:19,964 [102] FATAL org.dmxc.lumos.Kernel.Run.KernelRunManager - Console closed. Shutting Down!
2024-07-17 21:15:20,558 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Project_gService - Start saving Project.
2024-07-17 21:15:20,560 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project Clubset ...

[[[ Letzter Eintrag im Log ]]]
[[[ Konsolenfenster geschlossen ]]]

Lade ich nach dem Neustart von DMXC3 das Projekt, schlägt dies fehl, weil die letzte Version des Projekts kaputt ist (Projekt-Datei ist 0 KB groß und leer).

Bis zur Einführung der Project Administration war es möglich, das aktuell geladene Projekt über einen entsprechenden Konsolenbefehl im Kernel zu speichern. Diese Funktion sollte auch weiterhin bestehen und daher wieder aktiviert werden.

Das Art-Net-4-Plugin kann beim Start des Kernels nicht initialisiert werden mit folgender Meldung im Kernel:

19:24:14 ERROR AssemblyManager - Unhandled Exception when loading Types in Listener org.dmxc.lumos.Kernel.Plugin.PluginManager: Unable to load one or more of the requested types.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden.

Datenstand ist das Beta-Paket aus dem Forum vom 04.12.2024 und auch den letzten Jenkins-Jobs.

Ticket wurde nach Rücksprache von @JPK nun nochmal hierher übernommen und dient vornehmlich als Reminder.

Ich habe im beigefügten Projekt den ParameterMaster 2 aus dem Projekt gelöscht. Dieser war aber noch in einem Executor verknüpft. In diesem Kontext sind gleich mehrere Punkte aufgefallen:

• Beim Löschen des Masters wurde nicht darauf hingewiesen, dass dieser sowohl in einer Cue als auch in einem Executor verknüpft war.
• Das Projekt lässt sich nicht mehr laden und die GUI stürzt ab.

Der Kernel gibt hierzu folgende Fehlermeldung:

23:02:25 WARN  ProjectManager - Error when loading Project FS#5063 - Delete elements: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.Project.ExecutorManager.LoadExecutorMemberWrapperItem(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ExecutorManager.cs:line 390
   at org.dmxc.lumos.Kernel.Project.ExecutorManager.LoadAfterContainer(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ExecutorManager.cs:line 478
   at org.dmxc.lumos.Kernel.Project.ExecutorManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ExecutorManager.cs:line 662
   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass51_1.<LoadProjectFromStream>b__2(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 437
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:line 142
   at org.dmxc.lumos.Kernel.Project.ProjectManager.LoadProjectFromStream(ProjectVersionID id, Stream projectStream, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 432

Die GUI gibt parallel folgende Fehlermeldung:

2023-06-12 23:02:26,009 [2] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei LumosControlsWPF.Base.BasePropertyNotification.Dispose() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosControlsWPF\Base\BasePropertyNotification.cs:Zeile 164.
   bei LumosControlsWPF.Base.BasePropertyNotification.Finalize() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosControlsWPF\Base\BasePropertyNotification.cs:Zeile 67.

Das Problem ist aber nicht allein auf die Master beschränkt. Auch beim Löschen einer bereits mit einem Executor verknüpften Cuelist gibt es beim Löschen keinen Warnhinweis und beim erneuten Laden schlägt dies fehl.

Mit der Beta 11 ist das Rechnen mit Mastern in den Parametern eines Effekts nicht mehr zulässig. In welchem Wert für eine Funktion oder welcher Effekt dabei verwendet wird, ist dabei (offenbar) nicht relevant. Ich habe es unter anderem für die Effekte

• Bump
• PWM
• Chaser

sowie für die Funktionswerte

• Dimmer
• Strobe

probiert für unter anderem folgenden Syntax:

• Amplitude / Dimmer: {Parametermaster 1:*2} oder {Parametermaster 1: *2}
• Frequency / Duration / Strobe : {Speedmaster 1:/2}

Ich habe das Problem auf kritisch gesetzt, weil auf Grund dieses Fehlers alle Projekte nicht geladen werden können, in denen mit den Mastern gerechnet wurde.

Logs kann ich nicht beifügen, da im Moment der Bestätigung der Eingabe keine Einträge generiert werden. Es erscheint in der GUI nur die generische Fehlermeldung “Value not valid”.

Im Rahmen meines Livetests musste ich am vergangenen Wochenende feststellen, dass die komplette DMX-Ausgabe via Art-Net gegen Ende der Laufzeit der ersten Sitzung zunehmend ins Stocken geriet. Das war nicht nur auf den Geräten selbst zu sehen, auch die Status-LEDs der LAN-Buchsen der Switch oder die Aktivitäts-LED des Art-Net-Node zeitweise aussetze und nicht mehr kontinuierlich in hoher Frequenz blinkte - obwohl zu dem Zeitpunkt eigentlich kontinuierlich DMX-Werte hätten gesendet werden sollen. Nach dem Neustart von DMXControl 3 lief die zweite Sitzung ohne weitere Probleme durch.

Nennenswerter Unterschied war, dass er Laptop während der ersten Sitzung per WLAN mit dem Internet verbunden war und die Art-Net-Ausgabe per kabelgebundenen Netzwerk erfolgte. Vor dem Start der zweiten Sitzung habe ich die Verbindung ins WLAN getrennt und den Adapter abgeschaltet, sodass nur die kabelgebundene Verbindung zu den Art-Net-Nodes aktiv war.

Beim Betrachten der Logfiles ist zu sehen, dass nur bei der ersten Sitzung eine regelmäßige Info kam:

2022-09-10 18:29:27,488 [202] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - ArtPollReply shorter than 239 bytes, ignoring!

Grundlegend sind folgende Hinweise zu den Logfiles zu geben:

• Gegen 19:30 Uhr habe die Art-Net-Ausgabe auf einen anderen Port gewechselt und deswegen das Art-Net-Plugin abgeschaltet
• Ab ca. 21:15 Uhr begann der eigentliche Auftritt der Band an diesem Abend, wo dann in erster Linie nur noch Cuelists über ein Softdesk aufgerufen wurden
• Um 22:12 Uhr habe ich die erste Sitzung beeendet

Im Ticket FS#4790 hatte ich beiläufig berichtet, dass sich Kernel und GUI nicht mit dem Umbra verbinden, wenn der PC mit zwei Netzwerken verbunden ist. Was mir aber auch mehr oder minder regelmäßig passiert, wenn ich die Netzwerkkonfiguration ändere. Damit meine ich, dass

• der Laptop erst noch per WLAN und per Kabel mit einem Netzwerk verbunden war, ich aber dann die WLAN-Verbindung getrennt bzw. sogar den WLAN-Adapter abgeschaltet habe.
• ich aus bestimmten Gründen die Netzwerkkonfiguration ändere, sowohl Wechsel der statischen IP oder auch Wechsel von statischer IP-Adresse hin zu DHCP oder umgekehrt.

Auf meinem Laptop kann ich es mit der Beta 3 wie folgt reproduzieren:

• Variante 1: Meine Laptops sind per WLAN verbunden (Adresszuweisung per DCHP). Ich stelle eine kabelgebundene Verbindung zum gleichen Netzwerk her (Sowohl feste IP-Adresse über Zuteilung vom Router als auch DCHP) und deaktiviere die WLAN-Verbindung über den Infobereich in der Taskleiste. Diese Variante kann ich sowohl unter Windows 10 als auch Windows 11 nachvollziehen. (Zugehörige Logs unter Windows 10 siehe DMXControl3Logs_20221120_184500.zip)
• Variante 2: Bei meinem Laptop war das WLAN noch über Windows aktiv. Ich habe mein Handy per USB-Kabel angeschlossen, um darüber einen mobilen Hotspot zu erhalten. Dabei wird ein neues “kabelgebundenes” Netzwerk erstellt. Ich hatte dann erst das WLAN abgeschaltet und DMXC3.3 in der Beta 5 gestartet. Nach dem Start stellten GUI und Kernel keine Verbindung zum Umbra her. Auch ein Neustart von DMXC3 mit über Windows eingeschalten WLAN reichte nicht.

In dem genannten Fall muss ich meinen Laptop immer neu starten, wenn ich DMXC wieder nutzen möchte. Ob es noch weitere Randbedingungen gibt, versuche ich weiter herauszufinden. Vielleicht reicht aber diese Beschreibung bereits zum Lösen des Problems.

Das Ticket betrachtet das Problem des Verbindungsaufbaus unabhängig zum Ticket FS#4790.

Das Nanoloeaf-Plugin stellt die Ressourcen der genutzten Geräte nicht wie von DMXC selbst erwartet zur Verfügung, weswegen ein Projekt nicht gespeichert werden kann, sobald dort Nanoleaf-Elemente enthalten sind. Aus diesem Grund habe ich den Schweregrad auch auf “hoch” gesetzt.

Im Folgenden hierzu einmal der entsprechende Auszug aus den Logfiles. Von jedem aufgeführten Nanoloaf-Element war nur jeweils ein Element enthalten. Device Groups wurden nicht angelegt.

09:20:04 WARN  FileBackendDatastore - Following Resources could not be saved in Project:
{ "type": "DEVICE_IMAGE", "name": "Shapes" }
{ "type": "DEVICE_IMAGE", "name": "Canvas" }
{ "type": "DEVICE_IMAGE", "name": "LightPanles" }
09:20:04 ERROR ProjectManager - Error at save Project
org.dmxc.lumos.Kernel.Exceptions.ProjectIOException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Resource.LumosIOContext.ThrowOnWarnings() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\LumosIOContext.cs:Zeile 220.
   bei org.dmxc.lumos.Kernel.Project.ProjectManager.saveProject(String filename, Stream outputStream, IEnumerable`1 clientReferences, IProgress`1 progress, Boolean resetDirty) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 492.
09:20:04 WARN  ProjectManager - Unable to save project reference: Shapes in Project
09:20:04 WARN  ProjectManager - Unable to save project reference: Canvas in Project
09:20:04 WARN  ProjectManager - Unable to save project reference: LightPanles in Project

Mit der Beta 5 habe ich häufig insbesondere beim Speichern des aktuellen Projekts das Problem, dass die GUI abstürzt. Folgender Eintrag im Log der GUI zu finden.

2022-12-23 16:24:17,453 [Log-Thread] DEBUG Lumos.GUI.Run.GuiRunManager - InformSaveProject [before=True] took 105 ms
2022-12-23 16:24:17,531 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.User_gClient - UserContext of current User changed
2022-12-23 16:24:17,540 [92] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
System.InvalidOperationException: Der Vorgang ist aufgrund des aktuellen Zustands des Objekts ungültig.
   bei Lumos.GUI.Facade.User.UserContextFacade.ProcessDeviceChangedMessage(UserContextChangedMessage message) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\User\UserContextFacade.cs:Zeile 43.
   bei Lumos.GUI.Facade.GUISession.UserContextFacadeUpdater.<ProcessChange>d__3.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeUpdaters.cs:Zeile 38.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Facade.GUISession.FacadeContainer`2.<ProcessChangeMessage>d__21.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Facade\GUISession\FacadeContainer.cs:Zeile 142.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   bei Lumos.GUI.User.UserManager.<OnUserContextChanged>d__65.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\User\UserManager.cs:Zeile 282.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Der Kernel führt zu dem Zeitpunkt des Absturz folgende Aktionen aus:

2022-12-23 16:24:17,475 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Saving Project FS#4944 - Master window
2022-12-23 16:24:17,484 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - saveProject KernelInputManager.
2022-12-23 16:24:17,796 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Resource.FileAccessUtil - Deleted D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\Temp\b42fdf64-174b-4edc-97eb-b4cb45012ba3.tmp
2022-12-23 16:24:17,796 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Project.ProjectManager - Project FS#4944 - Master window successfully saved.

Mehr durch Zufall musste ich feststellen, dass die GUI direkt beim Start mit dem folgenden Logeintrag abstürzt, wenn statt des 3.3er-Kernels der 3.2.3er-Kernel läuft. Auch wenn die Konstellation eher ungewöhnlich ist, sollte diese trotzdem keinen Absturz hervorrufen.

2023-01-07 20:22:54,057 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
System.Net.Sockets.SocketException (0x80004005): Der Zugriff auf einen Socket war aufgrund der Zugriffsrechte des Sockets unzulässig
   bei System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   bei System.Net.Sockets.Socket.Bind(EndPoint localEP)
   bei LumosProtobuf.Udp.UdpListener.StartListen() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UdpListener.cs:Zeile 41.
   bei LumosProtobuf.Udp.UmbraDiscoveryClient.StartDiscovery(IReadOnlyCollection`1 listenAdresses) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraDiscoveryClient.cs:Zeile 66.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.NetTools_NetworkChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 175.
   bei org.dmxc.lumos.Kernel.Net.AbstractGrpcManager.StartupFinished() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\AbstractGrpcManager.cs:Zeile 167.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.InformManagerStartupFinished(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 372.
   bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.DoManagerTopDown(Func`2 action) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 142.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.startManager() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 340.
   bei Lumos.GUI.Run.GuiRunManager.startupGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Run\GuiRunManager.cs:Zeile 62.
   bei Lumos.GUI.Program.runGui() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 194.
   bei Lumos.GUI.Program.Main(String[] param) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Program.cs:Zeile 160.

Reproduzieren lässt sich dies, in dem ich den 3.2.3er Kernel manuell starte und dann Umbra und GUI über den Launcher aufrufe.