Bugtracker DMXControl 3

Möchte ich einen Position Master im Fanning-Manger des Position Panel verschieben, ist dieses exakt einmal möglich. Mit dem Verschieben verliert der Position Master die Auswahl und ich muss ihn erneut auswählen, um ihn weiter zu verschieben.

Ändere die Reihenfolge von Positionspunkten, kann ich dies mehrfach tun. Die gewählten Positionspunkte behalten ihre Auswahl bei.

Dieses Verhalten tritt im übrigen auch nur im Fanning Manager des Position Panel auf. Im Intensity Panel oder im Color Panel kann ich die dortigen Master mehrfach verschieben.

Ist kein Gerät ausgewählt, werden im Beam-Panel die Fader und im Gobo-Panel die Button-Fläche komplett ausgeblendet und durch einen entsprechenden Hinweistext ersetzt. Das gleiche Verhalten sollte aus meiner Sicht auch auf das Strobe- und Prism-Panel für die Buttons übertragen werden, statt diese mit einem Default-Wert auszugrauen. Insbesondere beim Prism-Panel ist der mit “Open” beschriftete ausgegraute Button eher unpassend.

Wähle ich ein Gerät ohne Gobos und ohne Prisma aus, werden die Fader in den entsprechenden Control Panel für meine Begriffe nicht “richtig” ausgegraut. Vielmehr suggerieren sie durch den blass-rot eingefärbten möglichen Faderweg und den unveränderten Faderknopf, dass die Funktion gegeben ist.

Beim Position-Panel werden die Fader dagegen sichtbar ausgegraut, wenn kein Gerät in der Stage View ausgewählt ist oder das aktuelle die Funktion nicht unterstützt.

Ich habe mal in der Tat Pixel gezählt und gemessen und bin dabei noch auf folgende Dinge gestoßen, die meiner Meinung nach nicht unterschiedlich sein müssen. Für die folgenden Anmerkungen

• habe ich die Panel nebeneinander eingedockt auf eine Höhe von 400 Pixel gezogen (gemessen am Rahmen)
• sind alle Panel in der Breite so groß, dass keine horizontale Scrollbar angezeigt wird
• nehme ich bezüglich Abstände etc. das Intensity-Panel als Bezugsgröße, sofern nicht anderes angeben

Strobe

• Randabstände der Buttons für Strobe-Modi weichen oben und unten vom Bezug ab
• Unterteilung sollte feiner sein

Beam

• Randabstände der Slider oben und unten stimmen nicht mit Bezugsgröße überein
• Faderknopf entspricht nicht der Größe der vom Dimmer- und Strobe-Fade

Prism

• Randabstände der Buttons für Prismen weichen oben und unten vom Bezug ab
• Abstand zwischen Slider für Index und Buttons sollte auf das gleiche Maß wie im Intensity-Panel gebracht werden

Gobo

• Randabstände oben und unten der Fläche für die Gobo-Icons weichen vom Bezug ab
• Abstand zwischen Slider für Index und Buttons sollte auf das gleiche Maß wie im Intensity-Panel gebracht werden

Position

• Die einfachen Fader könnten im hellen Theme zumindest das Farbschema der Fader im Intensity Panel etc. aufnehmen.

Im Installer fehlen gleich mehrere Dateien:

• GUI
  • Datei oder Assembly “JeremyAnsel.DirectX.DXCommon, Version=4.0.61.0, Culture=neutral, PublicKeyToken=null” für ShaderCache
  • Abhängigkeiten für den Colorpicker
• Kernel
  • Abhängigkeiten für diverse DMX-Interfaces
  • Abhängigkeiten für das Nanoleaf-Plugin
  • weitere Basis-Bibliotheken

Alle Details sind in den Logs zu finden.

Im Installationsverzeichnis der GUI können meines Erachtens alle Dateien aus dem Unterordner “Symbols” entfernt werden. Die dort enthaltenen Gif-Dateien wurden ja nur beim Laden und Speichern von Projekten ohne die Projektadministration verwendet.

Ich habe nach einigen anderen Arbeiten an dem in der Sitzung geladenen Projekt gegen 18:10 Uhr das Master-Fenster in den Vordergrund gerufen. Die Sitzung lief dabei seit rund vier Stunden. Beim Aufbau des Fensters hänge sich die GUI auf. Der Kernel und Umbra liefen weiter und nach dem Neustart der GUI konnte das Projekt “fortgesetzt” werden. Bei dem zweiten in den Vordergrund rufen des Master-Fensters wurde dieses ganz normal geladen.

Das Master-Fenster war Bestandteil des zuletzt geladenen Layouts des Projekts. Hierdurch war das Master-Fenster als weiterer Reiter in einem ausgedockten Fenster im Hintergrund geöffnet. Ich habe dieses Layout in beiden Fällen geladen.

Ich merke gerade auf meinen Laptop in den letzten Tagen sehr regelmäßig, dass der Kernel sich nicht lokal mit dem Umbra verbindet - obwohl ich alle drei Instanzen lokal ausführe.

Mein Wunsch wäre an dieser Stelle, den Kernel über einen Startparameter direkt zum Aufbau einer lokalen Verbindung zu zwingen, wodurch der automatische Verbindungsaufbau komplett deaktiviert wird.

Ich kann ja auch aktuell schon den Befehl “connect localhost” in den Kernel eingeben, selbst wenn der Umbra noch nicht gestartet ist. Sobald der Umbra gefunden wurde, kann der Befehl auch umgesetzt werden.

Ich stelle mir vor, dass beim Import von Word-Dokumente bestimmte Standard-Formatvorlagen wie Standard (-Text), Überschrift 1, Überschrift 2, Überschrift 3 etc. automatisch den Styles im Textbuch zugeordnet werden. Die Formatierung wie Schriftart, Schriftgröße, Schriftfarbe etc. im Word-Dokument wird aber dabei ignoriert. Es sollen die aktuellen Einstellungen der korrespondierenden Styles im Textbuch gelten.

Das Feld für die Executor-Nummer sollte mindestens so groß sein, dass drei Ziffern klar angezeigt werden. Diese Zahl kann vergleichsweise schnell erreicht werden.

Wie im beigefügten Screenshot zu sehen, werden aktuell selbst zwei Ziffern nicht vollständig dargestellt. Ich könne daher vorstellen, dass sich die Breite des Feldes an der Breite des Textes orientiert, um so bei wenigen Executoren wiederum noch mehr Platz für den Text zu haben.

Geräte, die als Matrix definiert sind, können über den Blackout nicht dunkel geschaltet werden. Dabei ist es egal, ob ein Matrix-Effekt angewendet wurde oder ob Dimmer und Farbe für die gesamte Matrix gesetzt wurden.

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.

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.

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

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

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

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.

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

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.

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.

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.

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 verschiedene Einstellungen für den AudioAnalzyer gesetzt und das Projekt gespeichert. Der Fokus liegt dabei auf den Einstellungen, die über die Dropdown-Menüs ausgewählt werden. Diese werden beim erneuten Laden nicht übernommen, sondern nur die Standartwerte gesetzt. Dazu zählen:

• Number of Bands für Spectrum
• Algorithm für Beat Detection
• Audio Device

In dem beigefügten Projekt sind die oben genannten Einträge entsprechend verändert.

Können sich zwei PCs im Netzwerk auf Grund unterschiedlicher IP-Adressen nicht erreichen, laufen in GUI und im Kernel stetig die folgenden Log-Einträge auf:

GUI

2025-08-17 00:46:48,187 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:48,188 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:51,607 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:51,608 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384411.606000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   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.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:53,640 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:53,641 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:46:55,818 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="failed to connect to all addresses", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384415.816000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1755384415.816000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}
   --- Ende der internen Ausnahmestapelüberwachung ---
   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.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:46:57,043 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:46:59,091 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:46:59,092 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:02,485 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="CANCELLED", DebugException="Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"") ---> Grpc.Core.Internal.CoreErrorDetailException: "CANCELLED"
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosProtobuf.ConnectionClient.UmbraConnectionClient.<>c__DisplayClass47_0.<<ProcessDiscoveryBroadcast>g__InformUmbraAskForActions|1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\src\UmbraConnectionClient.cs:Zeile 694.
2025-08-17 00:47:02,487 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384422.486000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   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.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.
2025-08-17 00:47:04,531 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 00:47:04,532 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 00:47:06,912 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 192.168.21.32
2025-08-17 00:47:07,940 [Log-Thread] DEBUG Lumos.GUI.Windows.Connection.NetworkExplorer - Unable to receive Info from Umbra
Grpc.Core.RpcException: Status(StatusCode="DeadlineExceeded", Detail="Deadline Exceeded", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}") ---> Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1755384427.939000000","description":"Deadline Exceeded","file":"..\..\..\src\core\ext\filters\deadline\deadline_filter.cc","file_line":81,"grpc_status":4}
   --- Ende der internen Ausnahmestapelüberwachung ---
   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.Windows.Connection.NetworkExplorer.<ProcessUmbraNetworkInfo>d__10.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Connection\NetworkExplorer.cs:Zeile 205.

Kernel

2025-08-17 16:51:24,632 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
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 694
2025-08-17 16:51:26,652 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:26,653 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:29,857 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
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 694
2025-08-17 16:51:31,895 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to connect to Umbra LICHT-LAPTOP-2 @ 127.0.0.1
2025-08-17 16:51:31,896 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to contact any of the Umbra LICHT-LAPTOP-2 IPs: [192.168.21.32, 127.0.0.1]
2025-08-17 16:51:35,299 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to inform Source Umbra LICHT-LAPTOP-2 @ 192.168.21.32...
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 694

Die Fehlermeldung lässt sich in folgender Konstellation reproduzieren, wenn beide an einem unmanaged Switch hängen und bei beiden Laptops zwei vollständige Sessions mit DMXControl 3.3.1 laufen:

• LICHT-LAPTOP-1: IP-Adresse 169.254.1.19 durch Windows vergeben, da Netzwerkprofil (noch) auf DHCP
• LICHT-LAPTOP-2: IP-Adresse 192.168.21.32, statisch vergeben

Ich habe an dieser Stelle die Erwartungshaltung, dass der Aufbau einer Verbindung in einem solchen Fall nach einer bestimmten Anzahl von Versuchen abgebrochen und ich als Nutzer darüber informiert werde - auch wenn der Versuch des Verbindungsaufbaus “nur” alle 5 Sekunden erfolgt. Der Mehrwert einer solchen Information liegt auch darin, dass mir aufgefallen wäre, dass die IP-Adresse des LICHT-LAPTOP-1 nicht passt und ich daraufhin nicht selbst vergeblich versuche, die GUI am LICHT-LAPTOP-2 anzumelden.

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).

In dem beigefügten Projekt wurden einfache Cuelist erstellt und die Farbe über zwei Wege definiert:

1. Manuelles Eingeben der Farbe im Device Control
2. Auswahl der Farbe über eine Colorlist, die als Default Color List definiert wurde.

Bei allen Cues und Presets, wo im die Farbe im Color Panel über die Default Color List ausgewählt wurde, wird die Farbe nicht eingefadet. Editiere ich die betreffende Cue oder das Preset, ändere die Farbe manuell ein wenig (254;0;0) und trage dann manuell den ursprünglichen Farbwert ein (255;0,0), wird die Farbe nach dem Aktualisieren der Cue bzw. des Presets wie erwartet eingefadet.

Der Fehler tritt sowohl in DMXC 3.3.0 als auch in DMXC 3.3.1 Beta 42 auf. Ob er auch schon in DMXC 3.2.3 existiert, habe ich nicht geprüft. Eine Diskussion zu diesem Fehler gibt es auch im Forum unter https://forum.dmxcontrol-projects.org/thread/18234/

Ich füge eine Special Cue für den Fader eines Macros ein und gehe dabei wie folgt vor:

1. Ich trage über die Tastatur den Wert “1.0” ein und drücke die Enter-Taste.
2. Ich ändere den Wert dann nochmal auf “0.25” und füge die Special Cue über “OK” der Cuelist hinzu.

Wenn ich die Special Cue wiedergebe, gibt diese den Wert “1.0” aus statt den zuletzt eingegeben Wert “0.25”.

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 habe im Draw Bitmap Node eine besondere Schriftart ausgewählt, welche nicht standardmäßig von Windows mitgeliefert wird. Das Projekt bearbeite ich auf einem anderen PC, wo diese Schriftart (noch) nicht installiert ist. In diesem Fall wird eine Default Schriftart als Rückfallebene gewählt. Speichere ich nun das Projekt auf diesem PC, wird die Default Schriftart in den Einstellungen des Draw Bitmap Nodes übernommen und damit die ursprünglich gewählte Schriftart überschrieben.

An dieser Stelle habe ich die Erwartung, dass sich die Einstellungen im Input Assignment ähnlich verhalten wie zum Beispiel im Softdesk. Hier wird bei einem Button die (temporäre) Änderung der Schriftart auf einen Default Wert nicht überschrieben, sollte eine Schriftart nicht verfügbar sein. Folglich zeigt der Button den Text später immer noch in der gewünschten Schriftart an, sobald ich entweder diese nachinstalliere oder das Projekt auf einem PC weiter bearbeite, wo die Schriftart bereits vorhanden ist.

Ich habe ein Projekt mit der Version 2.0.4 geöffnet und dann über eine gewisse Zeit mehrmals gespeichert. In den Logs des Kernels wird die Revisionsnummer allerdings nicht hochgezählt, wie im beigefügten Auszug zu sehen ist. Eigentlich müsste mit dem letzten Eintrag die Revisionsnummer bei 7 stehen. Die Projektdatei selbst wird richtig abgelegt.

18:20:06 INFO  Project_gService - Start saving Project.
18:20:06 INFO  ProjectManager - Saving Project Ehrung der Besten
18:20:08 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.
20:00:01 INFO  Project_gService - Start saving Project.
20:00:01 INFO  ProjectManager - Saving Project Ehrung der Besten
20:00:03 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.
20:26:00 INFO  Project_gService - Start saving Project.
20:26:00 INFO  ProjectManager - Saving Project Ehrung der Besten
20:26:03 INFO  ProjectManager - Version { "guid": "K4SS0GF8", "major": 2, "revision": 4 } of Project Ehrung der Besten successfully saved.

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

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.

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).

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”.

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.

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.

Aufbauend auf das Ticket  FS#5305  muss der DMXC-Mixer Node ebenfalls ergänzt werden. Aktuell kann ich über den DMXC-Mixer Node nicht ermitteln, ob ein Generic Switch aktiv ist oder nicht. Folgende Wege wären denkbar:

• Der Status wird mit in den Output “Intensity” aufgenommen, dem entsprechend Off = 0 und On = 1
• Das Node erhält einen zusätzlichen Output