Bugtracker DMXControl 3

In der Beta 3 von DMXControl 3.1.2 liegt möglicherweise ein Bug vor, weswegen über Art-Net nur ein DMX-Universum ausgegeben werden kann. Getestet und reproduziert werden kann das Problem mit zwei verschiedenen PCs mit unterschiedlichen Betriebssystemen (Windows 7 und Windows 10) sowie zwei verschiedenen Art-Net-Nodes. Die Konfiguration ist im beigefügten Screenshot dokumentiert.

In dem Projekt aus  FS#3668  kann das Softdesk ebenfalls nicht gespeichert werden - auch wenn man das nur lädt und einfach wieder auf speichern klickt, erhalte ich den folgenden Eintrag in den GUI-Logs:

2019-07-03 22:26:44,337 [4] ERROR Lumos.GUI.Windows.Softdesk.SoftdeskManager - Unable to save Softdesk Showdesk
System.Runtime.Serialization.SerializationException: Die Assembly "LumosGUI, Version=3.2.244.0, Culture=neutral, PublicKeyToken=null" kann nicht gefunden werden.

Server stack trace: 
   bei System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
   bei System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   bei System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   bei System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Exception rethrown at [0]: 
   bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   bei org.dmxc.lumos.Kernel.Resource.IResourceManager.saveResource(EResourceType type, LumosResource data)
   bei Lumos.GUI.Resource.ResourceManager.saveResourceInternal(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Resource\ResourceManager.cs:Zeile 537.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.saveResource(EResourceType type, LumosResource data) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 606.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskManager.SaveSoftdeskModelFile(SoftdeskModel model) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Softdesk\SoftdeskManager.cs:Zeile 338.

Die vollständigen Log-Files sind im Ticket  FS#3668  zu finden. Probleme beim Speichern des Softdesks im Projekt gab es zuletzt in dem im Ticket  FS#3433  beschriebenen Fehler.

Durch eine intensive und hochfrequente Beanspruchung des Kernels über einen MIDI-Controller ist dieser am Ende in einen Out-of-Memory-Fehler gelaufen und hat sich selbst beendet. Zuvor stockte die DMX-Ausgabe in zunehmender Intensität, während der Kernel versuchte den Arbeitspeicher freizuräumen.

Detaillierte Logs sowie ein Speicherabbild und ein Video sind intern zur Verfügung.

Auf Grund des folgenden Log-Eintrags kann die GUI nicht gestartet werden. Wenn ich das richtig lese, fehlt eine Datei im Installer.

2021-08-30 18:45:48,515 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Exception when initializing Manager SettingsManager: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
System.IO.FileNotFoundException: Die Datei oder Assembly "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Dateiname: "NGettext, Version=0.6.1.0, Culture=neutral, PublicKeyToken=08d3d1c89dfd2985"
   bei LumosLIB.Tools.I18n.T.LoadCatalog(CultureInfo culture, String dir)
   bei LumosLIB.Tools.I18n.T.InitializeCatalog(CultureInfo culture, String startupPath) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\I18n\T.cs:Zeile 94.
   bei Lumos.GUI.Settings.SettingsManager.org.dmxc.lumos.Kernel.Run.IManager.initialize() in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Settings\SettingsManager.cs:Zeile 96.
   bei org.dmxc.lumos.Kernel.Run.AbstractRunManager`2.ManagerInitAction(TManager m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Run\AbstractRunManager.cs:Zeile 646.

WRN: Protokollierung der Assemblybindung ist AUS.
Sie können die Protokollierung der Assemblybindungsfehler aktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1 festlegen.
Hinweis: Die Protokollierung der Assemblybindungsfehler führt zu einer gewissen Leistungseinbuße.
Sie können dieses Feature deaktivieren, indem Sie den Registrierungswert [HKLM\Software\Microsoft\Fusion!EnableLog] entfernen.

2021-08-30 18:45:48,529 [Main GUI] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Error in Startup
org.dmxc.lumos.Kernel.Exceptions.KernelPanicException: Error in Startup
2021-08-30 18:45:48,529 [Main GUI] INFO  DMXControl 3 GUI - GUI closing!

Im Anhang finden sich die vollständigen Logs inklusive die des Installers.

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

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

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.

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.

Werden Geräte einer Gruppe deaktiviert, auf denen verschiedene Cues abgelegt sind, lässt sich das Projekt nicht laden.

Um den Fehler zu reproduzieren, müssen im angehängten Projekt die Geräte DMB (1) und DMB (2) deaktiviert werden. Nach dem Speichern und neu Laden lässt sich das Projekt nicht mehr öffnen. Die Geräte sind in mehreren Gruppen enthalten. Zudem sind auf der Gruppe DMB-G mehrere Presents abgelegt.

Der Fehler lässt sich mit diesem Projekt auf verschiedenen PC reproduzieren. Ihn aber mit einem neuen Projekt nachstellen, war mir bislang nicht möglich. Die Session-ID für die Funktionsfähigkeit des Softdesk ist dem Dateinamen angehängt.

Nach dem Starten einer Cuelist mit einem Cue, in dem eine “leere” Farbtemperatur gespeichert ist, kam die folgende Fehlermeldung.

2018-03-07 22:56:40,359 [Main-Process-Chain] ERROR org.dmxc.lumos.Kernel.Run.MainProcessRunable - Removing Action DMXCMixer from Main Runable because of Exception Value is Empty!
org.dmxc.lumos.Kernel.Exceptions.UnsupportedConvertionException: Value is Empty
   bei org.dmxc.lumos.Kernel.PropertyType.Converter.KelvinConverter.convertToDoubleVector(Object value) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\PropertyType\Converter\KelvinConverter.cs:Zeile 22.
   bei org.dmxc.lumos.Kernel.PropertyValue.Fade.GenericConverterFader.fade(Object startValue, Object endValue, Double percentStart, Double percentEnd) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\PropertyValue\Fade\GenericConverterFader.cs:Zeile 77.
   bei org.dmxc.lumos.Kernel.PropertyValue.Fade.GenericConverterFader.fade(IPropertyValue start, IPropertyValue end, Double startPercent, Double endPercent) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\PropertyValue\Fade\GenericConverterFader.cs:Zeile 40.
   bei org.dmxc.lumos.Kernel.Mixer.AbstractMixerObject.getMixedValueInternal(Int32 startIndex, Double& fadePercent) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Mixer\MixerObject\AbstractMixerObject.cs:Zeile 441.
   bei org.dmxc.lumos.Kernel.Mixer.AbstractMixerObject.getMixedValueInternal() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Mixer\MixerObject\AbstractMixerObject.cs:Zeile 288.
   bei org.dmxc.lumos.Kernel.Mixer.AbstractMixerObject.getMixedValue() in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Mixer\MixerObject\AbstractMixerObject.cs:Zeile 266.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.setPropertyValue(IPropertyValue value, IMixable source) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 563.
   bei org.dmxc.lumos.Kernel.Mixer.DMXCMixer.processRegisterValues(RunContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Mixer\DMXCMixer.cs:Zeile 419.
   bei org.dmxc.lumos.Kernel.Run.MainProcessRunable.ActionBag.Invoke(RunContext ctx) in D:\Jenkins\workspace\Lumos_Stable_Release\Lumos\Lumos\src\Kernel\Run\Thread\MainProcessRunable.cs:Zeile 52.
2018-03-07 22:57:06,308 [57] DEBUG org.dmxc.lumos.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2018-03-07 22:57:06,521 [Main-Process-Chain] DEBUG org.dmxc.lumos.SceneFadeTicker - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2018-03-07 22:57:06,522 [Main-Process-Chain] DEBUG org.dmxc.lumos.SceneFadeTicker - Enqueuing for deregistration Auto: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2018-03-07 22:57:06,554 [Main-Process-Chain] DEBUG org.dmxc.lumos.SceneFadeTicker - Deregistriere toDeregister: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2018-03-07 22:57:06,555 [Main-Process-Chain] DEBUG org.dmxc.lumos.SceneFadeTicker - Deregistriere toDeregister: org.dmxc.lumos.Kernel.Scene.Fade.MixerFadeDecorator
2018-03-07 22:57:46,995 [46] FATAL org.dmxc.lumos.Kernel.Run.KernelRunManager - Console closed. Shutting Down!
2018-03-07 22:57:47,003 [46] DEBUG org.dmxc.lumos.Kernel.Project.ProjectManager - Session Kernel is saving Project MSK event GbR - Full Setup to Config\Backup\MSK event GbR - Full Setup_2018_3_7_22_57_46.zip.

Auf Grund einer System.OutOfMemoryException kam es zu einem Absturz der GUI. Logeintrag bei Systemzeit 2018-04-19 20:51:43,531. Log für Kernel und GUI im Anhang beigefügt.

Verändere ich auf meinem Test-Notebook die Größe der Stage View, indem ich das Device Control auf der rechten Seite oder die Control Windows an der Unterseite in ihrer Größe ändere, stürzt die Stage View reproduzierbar ab.

Die betreffenden Logfiles habe ich beigefügt.

Getestet mit Build 1409

Folgende Fehlermeldung erscheint im Log, wenn ich das angehängte Projekt öffnen möchte:

2019-01-07 22:13:42,439 [48] ERROR LumosLIB.Tools.LumosTools - Error loading Graphs in Project
System.ArgumentException: Source or Target node doesn't belong to this graph.
Parametername: e
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e, Boolean processGraph, Boolean reassignLevel) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 231.
   bei org.dmxc.lumos.Kernel.Input.v2.Graph.AddEdge(GraphEdge e) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Input\v2\Graph\Graph.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Input.v2.InputManager.org.dmxc.lumos.Kernel.Project.IProjectResourceUser<org.dmxc.lumos.Kernel.Input.v2.IGraph>.LoadItem(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Input\v2\InputManager.cs:Zeile 1141.
   bei org.dmxc.lumos.Kernel.Project.ProjectContainer`1.Load(LumosResource data, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Project\ProjectContainer.cs:Zeile 184.
   bei org.dmxc.lumos.Kernel.Project.Project.loadProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Release\Lumos\Lumos\src\Kernel\Project\Project.cs:Zeile 230.

Ich habe auch den Verdacht, dass auf Grund dieser Fehlermeldung das Projekt nicht geladen werden kann. Der Vorgang wird mit der Meldung “Project could not be loaded. Either the file is corrupt or not a valid project file” abgebrochen. Das Projekt verwendete ich gestern Nachmittag (Sonntag) zuletzt mit der Build 1402, unter der ich auch verschiedene Verbindungen im Input Assignment angelegt habe.

Getestet mit Build 1492

Nach dem Start der GUI passierte es häufig, dass abgesehen von der Menüleite oben und dem Schnellzugriff links keine weiteren Fenster anzeigt wurden (Bild 1). Bei einem Reset des Layouts verdeckt der Project Explorer die Fenster im angehängten Screenshot, jedoch nicht in der vollen Fenstergröße (Bild 2 und Bild 3). Erst nach einem Neustart von DMXControl 3.2 ist das Layout vollständig resettet.

2019-01-26 12:48:10,385 [1] ERROR Lumos.GUI.WindowManager - 
System.InvalidOperationException: Invalid Content: ActiveContent must be one of the visible contents, or null if there is no visible content.
   bei WeifenLuo.WinFormsUI.Docking.DockPane.set_ActiveContent(IDockContent value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPane.cs:Zeile 174.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.Activate() in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 736.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetParent(Control value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 881.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetPane(DockPane pane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 816.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetPaneAndVisible(DockPane pane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 781.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.SetDockState(Boolean isHidden, DockState visibleState, DockPane oldPane) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 582.
   bei WeifenLuo.WinFormsUI.Docking.DockContentHandler.set_PanelPane(DockPane value) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockContentHandler.cs:Zeile 444.
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.Persistor.LoadFromXml(DockPanel dockPanel, Stream stream, DeserializeDockContent deserializeContent, Boolean closeStream) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPanel.Persistor.cs:Zeile 617.
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.LoadFromXml(Stream stream, DeserializeDockContent deserializeContent) in C:\Users\Grote\Downloads\dockpanelsuite-Release_3.0 (1)\dockpanelsuite-Release_3.0\WinFormsUI\Docking\DockPanel.Persistor.cs:Zeile 799.
   bei Lumos.GUI.WindowManager.LoadWinFormUITheme(ThemeBase winFormUITheme) in D:\Jenkins\workspace\Lumos_Release\Lumos\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 854.

Getestet mit Alpha 3, Build 11

Erstelle oder ändere ich ein Softdesk und habe mein Projekt noch nicht gespeichert, sind alle Änderungen an dem betreffenden nach einem Schließen und Neustarten der GUI weg.

Getestet mit Alpha 3, Build 50

Ich lade das beigefügte Projekt, lege ein neues Softdesk an und erstelle im Input Assignment den im Screenshot gezeigten Graphen. Danach speichere ich das Projekt, schließe DMXControl 3, starte das Programm neu und öffne das Projekt. Dies wird aber nur zum Teil erfolgreich geöffnet. Der besagte Graph ist defekt, da beim Laden des Softdesks ein Fehler vorliegt. Entferne ich das Softdesk vor dem Speichern und Neustarten, tritt die Fehlermeldung auch nicht auf.

Projekt und Logfiles im Anhang.

Diese Fehler ist unabhängig vom Ticket  FS#3408 .

Ich habe bereits mit einer der Alpha-Versionen (Build 1554 und 1572) nach der Implementierung von MIDI ein Rule Set erstellt und dieses mit den genannten Versionen bearbeitet und ergänzt.

Füge ich das existierende Rule Set einem neuen, leeren Projekt hinzu und nehme anschließend nur eine einzige Änderung im Rule Set vor, wird das Projekt insofern fehlerhaft geladen, als dass alle Verbindungen im Input Assignment zu dem MIDI-Controller nicht mehr funktionieren. Setze ich die MidiSettings.xml manuell auf den Ursprungszustand zurück, sprich tausche die geänderte Fassung gegen die Initialfassung aus, kann das Projekt wieder vollständig und fehlerfrei geladen werden.

Der Auszug aus den Log sieht wie folgt aus:

2019-03-16 18:47:19,486 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Project.ProjectManager - Error when loading Project Temp\b5f1742c-653f-4a34-b83c-46ad462a3f21.tmp: Warnings in Project
ProjectLoad: WARNING: Unable to load project in MIDIManager(null)org.dmxc.lumos.Kernel.Exceptions.ProjectLoadException: Warnings in Project
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 68.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 139.
   bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
2019-03-16 18:47:19,508 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to load project in MIDIManager
2019-03-16 18:47:19,509 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to load project in MIDIManager
2019-03-16 18:47:19,971 [Log-Thread] INFO  org.dmxc.lumos.Kernel.GUISession.Session - Failed to load Project from GUI SKI-DSK-M4A89GA, Path F:\Verein\DMXControl Projects\Software\DMXControl 3\Testprojekte\DMXC 3.2\Beta-Test V3.2 Beta 1 (Testprojekt 1).zip

Im Anhang ist das Projekt mit den defekten MidiSettings sowie separat die MidiSettings.xml in der unveränderten Fassung zu finden. Zusätzlich sind die Logfiles beigefügt.

Der Installer liefert die Datei libartnet-1.dll möglicherweise im falschen Verzeichnis aus, welche gemäß der Logs aber für das Art-Net-Ausgabeplugin benötigt wird.

2019-03-16 19:13:55,326 [19] ERROR org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager+DMXInterfaceBag - Error setting interface DMXIM: ID Artistic License#ArtNet#0 enabled state to True:
System.DllNotFoundException: Die DLL "libartnet-1.dll": Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E) kann nicht geladen werden.
   bei org.dmxc.lumos.Kernel.DMX.ArtNetWrapper.artnet_new(String ip, Int32 verbose)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetInterface.OnEnable() in D:\Jenkins\workspace\Lumos_3.2_Release\DMXPlugins\ArtisticLicenseArtNet\src\ArtNet.cs:Zeile 180.
   bei DMXLIB.AbstractDMXInterface.set_Enabled(Boolean value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\DMXLIB\AbstractDMXInterface.cs:Zeile 91.
   bei org.dmxc.lumos.Kernel.Plugin.AbstractPluginManager.DMXInterfaceBag.SetEnabledInternal(Boolean state) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Kernel\Plugin\DMXInterfaceBag.cs:Zeile 226.
2019-03-16 19:14:17,088 [Log-Thread] DEBUG org.dmxc.lumos.SceneFadeTicker - Registriere: org.dmxc.lumos.Kernel.SceneList.ValuesStack.OutputValuesStack
2019-03-16 19:14:17,123 [Main-Process-Chain] ERROR org.dmxc.lumos.Kernel.Plugin.PluginManager - Exception DllNotFoundException occured 20 times.

Gemäß Installer-Log liegt die Datei in folgendem Verzeichnis:

Zielverzeichnis: C:\Program Files (x86)\DMXControl Projects\DMXControl 3.2\Kernel\Plugins\api-dlls
Wird entpackt: libartnet-1.dll... 100%

Ich erstelle eine Cuelist und verknüpfe diese im Input Assignment über den Cuelist Node zum Beispiel mit einer Taste der Tastatur, sodass in der Verbindung nur der Go- und Stop-Eingang am Node belegt sind. Dann speicher ich das Projekt, schließe es und lade es neu.

Nach dem erneuten Laden des Projekts hat das Cuelist Node die Werte für Intensity, Time und Speed überschrieben. Dies lässt sich beliebig wiederholen, wenn ich in der Cuelist die Werte manuell ändere. Erst wenn ich die drei Werte in den Cuelist Node selbst eintrage, bleiben diese auch nach dem Neuladen erhalten.

Unter DMXControl 3.1 habe ich das im Anhang befindliche DDF erstellt und live am Gerät erfolgreich geprüft. Das DDF war fehlerfrei.

Mit DMXControl 3.2 kann ich mit dem gleichen DDF jedoch keine Gobos mehr auswählen. Die Auswahl wird vom Control Windows für Gobo angenommen und auch vom Device Control übernommen, in der Stage View und vor allem am Gerät selbst kommt die Auswahl nicht an. Die Gobos sind wie folgt implementiert:

<step type="gobo" mindmx="65" maxdmx="69" val="Robe Robin 600E Spot Gobo 1 (Rad 2).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="65" maxdmx="69" minval="0" maxval="0" />
  <range handler="goboshake" mindmx="110" maxdmx="119" minval="0.4" maxval="10" />
</step>

<step type="gobo" mindmx="4" maxdmx="7" val="Robe Robin 600E Spot Gobo 1 (Rad 1).png" caption="Gobo 1">
  <range handler="goboshake" mindmx="4" maxdmx="7" minval="0" maxval="0" />
  <step for="goboindex" mindmx="4" maxdmx="7">
    <range handler="goboshake" mindmx="60" maxdmx="69" minval="0.4" maxval="10" />
  </step>
  <step for="goborotation" mindmx="32" maxdmx="35">
    <range handler="goboshake" mindmx="130" maxdmx="139" minval="0.4" maxval="10" />
  </step>
 </step>

Selbst beim Kopieren von nur drei Gobos eines Goborads ohne Zusätze wie Goborotation, Goboshake, Goboindizierung etc. in ein Test-DDF, wo neben dem Goborad zusätzlich nur ein Dimmer enthalten ist, funktioniert die Auswahl der Gobos nicht. Es wird jeweils nur das letzte Gobo aktiviert.

Reduziere ich den Dateinamen für das Icon um nur ein Zeichen auf 34 Zeichen zzgl. Dateiendung - also auf Robe Robin 600 Spot Gobo 1 (Rad 1).png (ohne das E) - arbeitet das DDF wieder fehlerfrei.

Zum Nachstellen des Problem habe ich im Anhang beide Varianten hochgeladen. Die alte Variante ist die Ursprungsvariante für DMXControl 3.1, die neue Variante ist die entsprechend korrigierte Variante mit dem verkürzten Dateinamen für DMXControl 3.2.

Im Ticket  FS#3470  wurde der Fehler behoben, dass durch das Markieren von Softdesk-Elementen die Größe des Objekts falsch ausgegeben wurde.

Vermutlich durch die Behebung dieses Fehlers wachsen die Elemente nun mit jedem Speichern und Neuladen des Projekt an, und zwar um jeweils 5 Pixel in Breite und Höhe. Durch ein mehrfaches Speichern und Neuladen meines Projekts (im konkreten Fall 2 Mal) kam dann folgendes im Anhang dargestelltes Ergebnis zu Stande. Bild 1 ist das Original, Bild 2 nach dem zweimaligen Neuladen des Projekts. Der Bildausschnitt ist jeweils der gleiche.

Ich füge einem neuen leeren Projekt zum Beispiel vier Clay Paky Alpha Spot QWO 800 hinzu und stelle eine beliebige Strobe-Frequenz bei geöffnetem Shutter und voller Helligkeit ein. Ist der Programmer hierbei geschlossen, kann ich Änderungen in der gesamten GUI soweit wie gewohnt vornehmen.

Sind Stage View und Programmer parallel geöffnet, reagiert die GUI deutlich verzögert, insbesondere die Control Windows und das Device Control, wo ich Werte über Regler einstellen kann. Im ungünstigsten Fall wird der Inhalt des Device Controls nicht aktualisiert bzw. nicht aufgebaut. Dies ist mir insofern zum Verhängnis geworden, dass ich eine Cue über “Edit in Programmer Blind” live nicht anpassen konnte.

Aktuell ist funktioniert das Cuelist Node nach dem Laden eines Projekts nicht, obzwar die ID vorhanden ist. Das Node arbeitet erst, wenn ich die Zuordnung kurz manuell ändere, zum Beispiel eine andere Cuelist auswähle. Speichere ich das Projekt und lade es erneut, besteht das Problem wieder. Ein Beispielprojekt ist beigefügt, wo ich eigentlich über “c” die Cuelist 1 starten möchte.

Dieses Ticket möchte sich Patrick alleine in Ruhe ansehen.

Ist bei einem Cuelist Node das Feld für Fade Factor leer, kann ich die Intensity und den Speed Factor über ein Slider im Softdesk oder einen MIDI-Controller nicht steuern und die Werte werden auch am Output-Hub ausgegeben. Sobald das Feld einen Wert erhält (welcher auch 0 sein kann) funktioniert die Ansteuerung und das Feedback.

Im Anhang die Log-Files und ein Beispiel-Projekt.

Verknüpfe ich einen Slider vom Softdesk mit dem Value-Input eines Parameter Masters, so werden diese Werte nicht weiterverarbeitet. Dies betrifft sowohl den Output-Hub des Nodes selbst als auch den Parameter Master im Master Window.

Im Anhang sind die Logs sowie ein Beispiel-Projekt zu finden.

Ich habe ein Projekt mit mehreren Speedmastern gebaut. Lade ich das gleiche Projekt noch einmal neu, kann ich die Werte im Masterfenster zwar ändern oder über das Input Assignment triggern, in den Cuelists kommt nichts mehr an. Hier laufen die Cuelists dann mit der beim Starten der Sitzung (nach dem initialen Laden des Projekts) weiter.

Nutze ich das im Anhang beigefügte DDF, hängt sich die GUI komplett auf, sobald ich den Dialog Add Device schließe. Ersetze ich den vom Kernel bemängelten Code

<ptspeed dmxchannel="8">
  <step type="linear" mindmx="255" maxdmx="0" minval="0" maxval="255" />
</ptspeed>

durch den folgenden, korrigierten Code

<ptspeed dmxchannel="8">
  <range type="linear" mindmx="0" maxdmx="255" minval="100" maxval="0" />
</ptspeed>

lässt sich das DDF ganz regulär hinzufügen und auch die GUI arbeitet ohne Probleme weiter.

Die Logs bis zum Zeitpunkt des Aufhängens der GUI sind ebenfalls beigefügt.

Bei der Vorabprüfung von  FS#4011  und auch  FS#3964  in einem meiner Hauptprojekte fiel mir auf, dass der Speedmaster- und Parametermaster-Node komplett tot sind. Sie verarbeiten keinerlei Daten am Input und geben an den Outputs keine Daten zurück, auch nicht in einem neuen, leeren Standard-Projekt. Für das Reproduzieren reicht es, das Node in ein Connectionset hinzuzufügen und die Master über das Masterfenster zu verändern.

Der Fehler hat sich nach dem Build 576 eingeschlichen. In der Build 576 arbeiten die Nodes dagegen noch einwandfrei.

Getestet mit DMXControl 3.2.1, Build 600

Lege einen beliebigen Effekt im Device Control auf eine beliebige Funktion eines Geräts, werden jegliche Änderungen an den Parametern des Effekts in der Stage View und der DMX-Ausgabe nicht umgesetzt. Einzig der Effektvisualiser generiert die richtige Vorschau auf Basis der gesetzten Parameter.

Speichere ich den Effekt in einer Cue ab, so wird dieser entsprechend der im Blindflug eingestellten Parameter beim Abspielen der Cue richtig wiedergegeben und auch beim Editieren der Cue zeigt die Stage View den Effekt richtig an. Alle folgenden Änderungen registriert die Stage View und die DMX-Ausgabe jedoch nicht.

Logs der Sitzung siehe Anhang. Auffällig sind hier die beiden folgenden Einträge, welche nach dem Aufruf eines leeren Projekts erschienen:

2020-01-15 20:21:02,619 [305] ERROR org.dmxc.lumos.Kernel.Command.Command - Error while invoking Command: getEffectVectorsFromProgrammer, Paras: 
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 70.
   bei org.dmxc.lumos.Kernel.Command.Command.execute(Object[] paras) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\Command.cs:Zeile 121.
2020-01-15 20:21:02,647 [305] ERROR org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory - TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei org.dmxc.lumos.Kernel.Command.KernelCommandFactory.getEffectVectorsFromProgrammer(String sessionName, String groupID, String propID, String effectID) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\KernelCommandFactory.cs:Zeile 2262.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei org.dmxc.lumos.Kernel.Command.ReflectionCommandFactory.CommandPropertyBag.Invoke(CommandParameterList list) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\Lumos\src\Kernel\Command\ReflectionCommandFactory.cs:Zeile 60.

Ich habe in einem Projekt verschiedene Presets auf eine Device Group (konkret Futurelight DMH-80) gelegt und diese Presets dann als Property Preset in verschiedenen Cues eingesetzt.

Ersetze ich (egal ob manuell oder durch die Funktion “Replace devices”) nun alle Geräte in der Device Group, “auf” der das Preset abgelegt ist, vollständig durch einen anderes Gerät (hier Robe Robin 600e Spot), kann das Projekt nach dem Neustart der Sitzung nicht mehr geladen werden.

Aus den Logs von der Vorbereitung der Veranstaltung zum vergangenen Samstag kann ich folgenden Eintrag hierzu entnehmen:

Kernel

2020-01-25 12:09:39,291 [55] ERROR org.dmxc.lumos.Kernel.Scene.Entry.PresetEntry - Didn't find matching DeviceProperty for GUI. Searched for GPW: DimmerProperty in Group Temporary DeviceGroup: , ID: 8b764e55-d1a3-477a-9c69-2d6baeef5f47-SDG

GUI

2020-01-25 12:09:39,292 [ConnectionManager-MessageDispatcher] ERROR Lumos.GUI.Facade.EventWrapper - Exception in Event: There is no Property with the ID: 07a653c6-ec70-48a4-bd6c-82877c93f6db in this DeviceGroup
Parametername: prop
System.ArgumentNullException: There is no Property with the ID: 07a653c6-ec70-48a4-bd6c-82877c93f6db in this DeviceGroup
Parametername: prop
   bei Lumos.GUI.Facade.Scene.Entry.SceneEntryFacade.get_GUIDeviceProperty() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\Scene\Entry\SceneEntryFacade.cs:Zeile 133.
   bei Lumos.GUI.Windows.ProjectExplorer.TreeBranches.PresetBranch.<>c.<SyncPresetInCorrectFolder>b__15_0(IGUISceneEntry c) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\TreeBranches\PresetBranch.cs:Zeile 151.
   bei System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   bei System.Linq.Enumerable.<DistinctIterator>d__64`1.MoveNext()
   bei System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   bei System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   bei Lumos.GUI.Windows.ProjectExplorer.TreeBranches.PresetBranch.SyncPresetInCorrectFolder(IPresetFacade facade) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\TreeBranches\PresetBranch.cs:Zeile 151.
   bei Lumos.GUI.Windows.ProjectExplorer.TreeBranches.PresetBranch.GuiSession_PresetChanged(Object sender, PresetChangedEventArgs args) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\ProjectExplorer\TreeBranches\PresetBranch.cs:Zeile 137.
   bei Lumos.GUI.Facade.EventWrapper`1.raise(Object o, TEventArgs args) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\EventWrapper.cs:Zeile 84.
2020-01-25 12:09:39,480 [Main GUI] ERROR Lumos.GUI.Controls.DataGrid.PresetRow - There is no Property with the ID: 07a653c6-ec70-48a4-bd6c-82877c93f6db in this DeviceGroup
Parametername: prop
System.ArgumentNullException: There is no Property with the ID: 07a653c6-ec70-48a4-bd6c-82877c93f6db in this DeviceGroup
Parametername: prop
   bei Lumos.GUI.Facade.Scene.Entry.SceneEntryFacade.get_GUIDeviceProperty() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\Scene\Entry\SceneEntryFacade.cs:Zeile 133.
   bei Lumos.GUI.Controls.DataGrid.PresetRow.<>c.<Update>b__10_1(IGUISceneEntry c) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Controls\DataGrid\PresetRow.cs:Zeile 61.
   bei System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   bei System.Linq.Enumerable.<DistinctIterator>d__64`1.MoveNext()
   bei LumosLIB.Tools.LumosTools.Implode[T](IEnumerable`1 source, String delim) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosLIB\src\Tools\LumosTools.cs:Zeile 1187.
   bei Lumos.GUI.Controls.DataGrid.PresetRow.Update() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Controls\DataGrid\PresetRow.cs:Zeile 60.

Die beigefügten Logfiles zeigen den Versuch, das Projekt nach dem Neustart des Sitzung zu laden. Auf Wunsch, kann ich noch ein entsprechendes fehlerhaftes Projekt zur Verfügung stellen.

Klone ich ein bestehendes Connectionset mit mehreren Nodes, so werden die darin verwendeten Nodes nicht aktualisiert bzw. aktiviert. Dadurch arbeitet das Connectionset nicht wie gewünscht. Der beigefügte Screenshot zeigt die Situation nach dem Klonen. Das Connectionset selbst als auch die zugehörige Bank ist aktiv.

Dieses Ticket ist (möglicherweise) ein Seiteneffekt vom Ticket  FS#4129 , der dort bereits schon angemerkt wurde.

Problem siehe oben und lässt sich wie folgt reproduzieren:

1. Slider mit Parametermaster 1 verknüpfen.
2. Connectionset deaktivieren.
3. Im Parametermaster-Node einen anderen Parametermaster, zum Beispiel Parametermaster 2 auswählen.
4. Connectionset aktivieren.

Das Ergebnis ist, dass der Slider nach dem Reaktivieren des Connectionsets weiterhin den Parametermaster 1 anspricht, obwohl im Connectionset auf der Inputseite die ID des Parametermaster 2 vermerkt ist. Diese wurde intern nicht weiterverarbeitet. Gleiches lässt sich mit dem Cuelist-Node reproduzieren.

Ich habe eine Cuelist mit einer einzigen Cue erstellt, in der relativ ein Circle-Effekt auf einer Gruppe von Moving-Heads läuft. Beim Starten der Cuelist wird die Bewegung wie erwartet eingefaded.

Stoppe ich die Cuelist aber, gibt diese die Bewegung trotz laufender Release Time im vollen Maß aus. Ist die Zeit abgelaufen und Cuelist ist deaktiviert, springen die Geräte zur Ursprungsposition zurück.

Dupliziere ich die Cue und ändere diese von REL zu ABS ab, verhält sich die Cuelist während der laufenden Release Time wie erwartet, das heißt die Geräte fahren langsam zur Ursprungsposition zurück. Gleiches gilt analog auch für den Dimmer oder die Goborotation.

Das 3Dconnexion-Plugin kann beim Starten der GUI nicht initialisiert und deswegen zur Zeit auch nicht genutzt werden. Das Log der GUI sagt hierzu folgendes:

2020-10-08 13:16:17,904 [Main GUI] ERROR Lumos.GUI.Plugin.PluginManager - Error when initializing Plugin: _3DxPlugin
System.ArgumentException: Das Argument picture muss ein Bild sein, das als Icon verwendet werden kann.
   bei System.Drawing.Icon.Initialize(Int32 width, Int32 height)
   bei System.Drawing.Icon..ctor(Stream stream, Int32 width, Int32 height)
   bei System.Drawing.Icon..ctor(Stream stream)
   bei Lumos3DconnexionPlugin._3DxForm..ctor()
   bei Lumos3DconnexionPlugin._3DxPlugin.initializePlugin()
   bei Lumos.GUI.Plugin.GuiPluginBase.initializePlugin(IGuiPluginContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\GuiPluginBase.cs:Zeile 52.
   bei Lumos.GUI.Plugin.PluginManager.initializePlugin(Type t) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\PluginManager.cs:Zeile 581.
   bei Lumos.GUI.Plugin.PluginManager.org.dmxc.lumos.Kernel.AssemblyScan.IAssemblyListener.scanNewType(Type t, EAssemblyType type) in D:\Jenkins\workspace\Lumos_Pipeline_3.2\LumosGUI\src\Plugin\PluginManager.cs:Zeile 561.

Zur Zeit ist es nicht möglich, im Standard-Theme zwischen absoluten Werten (ABS) und relativen Werten (REL) umzuschalten. Dies klappt nur im Dark Theme.

Der Installer liefert den GUI-Teil des Nanoleaf-Plugins nicht mit aus. Deswegen wirft der Kernel möglicherweise unter anderem folgende Fehlermeldung.

2021-04-13 21:51:08,533 [29] INFO  Nanoleaf_Plugin.NanoleafPlugin - Stop Plugin: Nanoleaf-Plugin
2021-04-13 21:51:08,534 [29] DEBUG Nanoleaf_Plugin.NanoleafPlugin - Request stop for DiscoverTask
2021-04-13 21:51:08,534 [29] DEBUG Nanoleaf_Plugin.NanoleafPlugin - Await DiscoverTask stopped

Im Anhang das Logfile des Installers.

Ich kann auf einem zweiten PC keine zweite, komplett eigenständig laufende Instanz von DMXC3 ausführen, wenn sich beide PCs im gleichen Netzwerk befinden. Dabei macht es keinen Unterschied, ob ich die Komponenten gemeinsam starte oder manuell Komponente für Komponente. Im Network Explorer werden mir beide Instanzen angezeigt. Ich kann auf dem PC 2 aber keine Verbindung zum lokal ausgeführten Kernel herstellen. Ziehe ich die Verbindungslinie von der GUI zum Umbra und vom Umbra zum Kernel, so blinkt diese kontinuierlich. Bei der Instanz auf dem zweiten PC vermeldet der Kernel hierbei immerzu folgenden Eintrag im Log, selbst wenn ich über die GUI versuche, diesen “einzufangen” und ihn dazu bewegen möchte, sich mit dem Umbra auf PC 2 zu verbinden.

2021-04-25 01:32:14,390 [Log-Thread] INFO  org.dmxc.lumos.Kernel.Net.GrpcManager - Connecting to Umbra Server on Host 192.168.21.22:17475
2021-04-25 01:32:14,393 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Login Call: 1ms
2021-04-25 01:32:14,393 [42] ERROR org.dmxc.lumos.Kernel.Net.gService.Umbra_gService - Unable to Login to Umbra Server: Client limit reached. Only 1 Clients of Type Kernel allowed.

Eine solche Konstellation sollte aber möglich sein. Anwendungsfälle gibt es hier genügend. Aktuell kann ich einen parallelen Test auf meinem zweiten PC nur ausführen, wenn ich zum Beispiel den Netzwerkadapter deaktiviere.

Im Anhang sind die Logfiles aus der Konstellation, bei der alle Komponenten manuell gestartet wurden.

Marcel hat eine neue Version der Nodle_USB.dll erstellt. Diese Anpassung muss in DMXControl 3 selbst noch entsprechend vorgenommen werden.

Die neue Version wird im Nodle Config Tool bereits verwendet.

Aktuell ist ein lineares Fanning mit dem Positionmaster und einem festen Wert nicht möglich. Bei der Eingabe von zum Beispiel {Positionmaster 1} > 0;0 erscheint folgende Fehlermeldung.

2021-05-15 19:25:01,506 [51] ERROR LumosLIB.Tools.gRPC.GrpcTools - Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
2021-05-15 19:25:01,516 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Net.gService.DuplexStreamHandler - Exception in Delegate Invocation: Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest]) => org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.Void _setProgrammerValue_RequestReceived(System.Object, org.dmxc.lumos.Kernel.Net.gService.RequestEventArgs`1[LumosProtobuf.SetProgrammerValueRequest])
System.Runtime.Serialization.SerializationException: Unable to Serialize Element of Type: org.dmxc.lumos.Kernel.Scene.Fanning.LinearFannedValue
   bei LumosLIB.Tools.gRPC.GrpcTools.ToObjectData(Object obj, EFallbackEnforcement fallbackEnforcement) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 307.
   bei LumosLIB.Tools.gRPC.GrpcTools.ToPropertyValue(Object value) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Tools\GRPC\GrpcTools.cs:Zeile 149.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService.ReadPropertyValueData(IUserContext uc, String groupId, String propertyId) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 217.
   bei org.dmxc.lumos.Kernel.Net.gService.Programmer_gService._setProgrammerValue_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_master\Lumos\src\Kernel\Net\gService\Programmer_gService.cs:Zeile 268.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass3_0`1.<InvokeFailSafe>b__0(EventHandler`1 a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 28.
   bei LumosToolsLIB.Tools.EventTools.<>c__DisplayClass9_0`1.<InvokeFailSaveGeneric>b__0(TDelegate a) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 62.
   bei LumosToolsLIB.Tools.EventTools.InvokeFailSaveGeneric[TDelegate,TReturn](TDelegate delegate, Func`2 invoker, ILumosLog elog) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosToolsLIB\src\Tools\EventTools.cs:Zeile 82.

Hierbei friet die GUI ein und ist nicht mehr bedienbar. Ich muss die GUI hierzu abschießen und dann nach dem Neustart den Programmer leeren, um weiterarbeiten zu können. Ein Fanning über zwei Positionmaster entsprechend {Positionmaster 1} > {Positionmaster 2} ist dagegen möglich. Im Bereich des Colormasters tritt ein vergleichbarer Fehler ebenfalls nicht auf.

Im Anhang die Logfiles der Sitzung, bis die GUI einfriert und über den Taskmanager geschlossen werden muss.

Ich habe ein Projekt erstellt, in dem insgesamt 672 Geräte und 28 Gerätegruppen gepatcht und in zahlreichen Ordnern abgelegt.

Das Laden des Projekt schlägt jedoch mit einer Fehlermeldung fehl. Ignoriere ich diese, fallen gibt es folgende Fehler:

• die Zuordnung der Geräte und den Gerätegruppen zu den Ordnern schlägt ca. zu 80% fehl
• in den beiden Stage Views fehlen Icons von Geräten und Gerätegruppen

Spannenderweise liegen die Positionsinformationen der Icons in den Stage Views grundsätzlich noch vor. Ziehe ich die fehlenden Icons wieder in die Stage View, werden diese an der richtigen Position eingefügt.

Lade ich das gleiche Projekt mit der 3.3 Alpha 4, so funktioniert das Projekt ohne Probleme.

Im Anhang findet sich das betreffende Projekt sowie die Logs eines Durchlaufs einer Sitzung.

Ich habe mir ein Projekt erstellt, um die verschiedenen Executor-Typen zu testen und zu dokumentieren. Die Belegung der verschiedenen Seiten ist in den beigefügten Screenshots zu sehen. Die verschiedenen Executoren enthalten dabei auf allen Seiten mehrfach die gleichen Elemente, damit ich insbesondere auch die zahlreichen Buttons prüfen kann. Soweit ich das überblicke, werden diese Informationen auch richtig in die Datei “ExecutorMemberWrappers.xml” geschrieben.

Beim erneuten Laden des Projekts direkt aus der laufenden Sitzung heraus oder auch beim Laden des Projekts nach einem Neustart von DMXC werden die Belegung der Executor-Pages augenscheinlich unvollständig bzw. gar nicht geladen - insbesondere bei den “hinteren” Executor-Pages (im aktuellen Beispiel Group Master, Parameter Master etc.). Beim Betätigen des Faders des Executor 2.1 (Executor Page Group Master) kann man aber erkennen, dass eine Verknüpfung im Hintergrund noch existiert. Die Fader der Executoren 2.2 und 2.3 bewegen sich mit. Gleiches fällt auf, wenn man die Belegung der Executoren ändern möchte. Es wird erst beim zweiten Ablegen eines Elements auf den Executor wirklich das neue Element angezeigt.

Im Anhang findet sich neben den Screenshots des Sollzustands das zugehörige Projekt sowie die Logfiles, die nach dem Neustart und Laden des Projekts generiert wurden.

Ändere ich bei einem bereits einmal gespeicherten und wieder geöffneten Projekt zum Beispiel bei einer Auswahl von Devices in der Stage View die Einstellung “Enabled”, so friet die GUI ein. Um weiterarbeiten zu können, muss ich den Prozess “hart” über den Task Manager beenden.

Dieses Ticket beschreibt den eigentlich beobachteten Fehler aus Ticket FS#4683. Im Nachhinein betrachtet war es dort die gleiche Vorgehensweise, nur eben mit dem Eintrag “Mirror horizontal”. Hier war das Projekt zum Zeitpunkt des Auftreten des Fehlers zuvor ebenfalls innerhalb der Sitzung nochmal neu geladen worden.

Im Anhang befindet sich das Projekt sowie die Logfiles, wobei die der GUI nur bis zu dem Zeitpunkt erfasst sind, bis diese über den Taskamanager beendet wurde.

Um das Ticket  FS#4525  nicht nochmal komplett zu öffnen, ziehe ich den dort vermerkten Punkt 3 mit etwas abgewandelter Beschreibung nochmal auf, nachdem er mit im Kontext von  FS#4771  bewusst (wieder) aufgefallen ist:

Zwischen dem ersten und zweiten Gerät in der Device Group nicht nahtlos statt findet der Wechsel bzw. die Umschaltung zwischen dem. Hier gibt es einen kurzen Augenblick, bei dem das Gerät 1 bereits aus aber das Gerät 2 noch nicht an ist und so ein Blitz entsteht. Dieser Punkt ist gut in dem beigefügten Projekt sowohl in der Stage View als auch auf meinen LED-Bars in Realität zu sehen. Ich habe hier

• einen Custom Chaser mit nur zwei Schritten, wo das Group Handling auf 2 gesetzt ist sowie
• einen einfachen Chaser mit Playmode Normal, jedoch mit einem “hohen” Wert für das Group Handling

in der Cuelist gespeichert.

In der Summe ist das Phänomen mit (allen) anderen Playmodes reproduzierbar und fällt zunehmend stärker auf, umso größer der Wert für das Group Handling ist.

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.