Bugtracker DMXControl 3

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

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.

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.

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.

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.

Wenn ich ein beliebiges Projekt schließe, dann crasht jedes Mal die GUI. Dabei spielt es keine Rolle, ob es ein bereits gefülltes Projekt ist, oder wie beigefügt, ein neues und komplett leeres Projekt.

Es gibt zwar ein weiteres Ticket mit einem vergleichbaren Titel unter der Nummer  FS#4986 , allerdings konnte ich das Problem seiner Zeit nicht nachstellen. Außerdem ist der Punkt nun bei mir in der aktuellen Version erst neu aufgetreten.

Im Anhang die Log-Dateien sowie das Projekt.

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.

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

Beim Laden eines Projekts mit der Beta 9, welches zuletzt mit der Beta 8 gespeichert wurde, tritt folgender Fehler auf. Es hat mal wieder etwas mit dem PositionMaster zu tun, wo ich einen angepassten Wertebereich von 0;-45 bis 0;45 hinterlegt habe.

22:44:43 WARN  ProjectManager - Error when loading Project: Input must be >= inMin [0] (Parameter 'input')
Actual value was -45.
System.ArgumentOutOfRangeException: Input must be >= inMin [0] (Parameter 'input')
Actual value was -45.
   at LumosLIB.Tools.LumosTools.RuleOfThree(Double input, Double inMax, Double inMin, Double outMax, Double outMin, ERuleOfThreeBehavior behavior) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:line 537
   at org.dmxc.lumos.Kernel.Master.PositionMaster.UpdateRelativeValueFromPosition(Position position) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\PositionMaster.cs:line 125
   at org.dmxc.lumos.Kernel.Master.PositionMaster.set_Position(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\PositionMaster.cs:line 89
   at org.dmxc.lumos.Kernel.Master.PositionMaster.set_Min(Position value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\PositionMaster.cs:line 209
   at org.dmxc.lumos.Kernel.Master.PositionMaster.LoadFromManagedTree(ManagedTreeItem m, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\PositionMaster.cs:line 252
   at org.dmxc.lumos.Kernel.Master.MasterManager.LoadBeforeContainer(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\MasterManager.cs:line 815
   at org.dmxc.lumos.Kernel.Master.MasterManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Master\MasterManager.cs:line 747
   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass51_1.<LoadProjectFromStream>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 425
   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 420
   at org.dmxc.lumos.Kernel.Project.ProjectManager.LoadProjectFromProjectStore(ProjectVersionID id, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 344
   at org.dmxc.lumos.Kernel.Net.gService.Project_gService._loadProjectVersion_RequestReceived(Object sender, RequestEventArgs`1 args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Project_gService.cs:line 622

Mit dem beigefügten Testprojekt lässt sich der Fehler nachstellen.

Es zeigte sich zuletzt, dass unter anderem die Graphs.xml wegen eines OutOfMemory-Exeption nicht gespeichert werden kann, wenn die Graphen im Input Assignment entsprechend umfangreich ausfallen.

Um das Problem zu beheben, sollen verschiedene Dateien im Projekt automatisch in rollierender Weise aufgeteilt werden, wie es in etwa auch bei den Log-Dateien bereits gemacht wird.

Im beigefügten Projekt habe ich nur ein Macro angelegt, welches zwei statt nur einem Fader beinhaltet. Die Anzahl der Buttons habe ich nicht geändert.

Versuche ich dieses Projekt zu laden, schlägt dies mit folgender Fehlermeldung im Kernel fehl:

System.Exception: This Macro havn't a Fader with Number 2
   at org.dmxc.lumos.Kernel.Macro.Macro.setFaderLabel(Byte number, String label) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Macro\Macro.cs:line 132
   at org.dmxc.lumos.Kernel.Macro.Macro.LoadFromManagedTree(ManagedTreeItem m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Macro\Macro.cs:line 248
   at org.dmxc.lumos.Kernel.Macro.MacroManager.LoadBeforeContainer(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Macro\MacroManager.cs:line 247
   at org.dmxc.lumos.Kernel.Macro.MacroManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.loadProject(LumosIOContext context, ELoadTime time) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Macro\MacroManager.cs:line 236
   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass51_1.<LoadProjectFromStream>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 426
   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 420

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.

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.

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.

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.

Wenn man die Properties des Timer-Nodes öffnet, wirft der Kernel den folgenden Fehler. Offenbar wurden die Icons für die verschiedenen Modi verschoben, sodass diese nicht mehr zu finden sind. Im Dropdown vor den Modi sind die Icons zumindest leer.

19:45:46 FATAL DMXControl 3 Kernel - Unhandled Exception: Could not find the resource "org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" among the resources "Lumos.Properties.Resources.resources", "Lumos.Properties.Shaders.resources", "Lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" embedded in the assembly "Lumos", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
System.Resources.MissingManifestResourceException: Could not find the resource "org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" among the resources "Lumos.Properties.Resources.resources", "Lumos.Properties.Shaders.resources", "Lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.resources" embedded in the assembly "Lumos", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
   at System.Resources.ManifestBasedResourceGroveler.HandleResourceStreamMissing(String fileName)
   at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists)
   at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
   at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture, Boolean wrapUnmanagedMemStream)
   at System.Resources.ResourceManager.GetObject(String name, CultureInfo culture)
   at org.dmxc.lumos.src.Kernel.Input.v2.Graph.Node.Worker.Converter.TimerNodeImages.get_TIMER_png() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\TimerNodeImages.Designer.cs:line 118
   at org.dmxc.lumos.Kernel.Input.v2.Worker.Effect.TimerNodeResourceProvider.loadResource(EResourceDataType type, String name) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Worker\Converter\TimerNode.cs:line 403
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.<>c__DisplayClass71_0.<TryLoadResourceCore>b__1(IResourceProvider c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 564
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Func`2 predicate, Boolean& found)
   at org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.TryLoadResourceCore(EResourceDataType type, String name, EResourceSource source, EIOFlags flags, Boolean sync) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:line 562
   at org.dmxc.lumos.Kernel.Net.gService.Resource_gService._loadResource_RequestReceived(Object sender, RequestEventArgs`1 args) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\gService\Resource_gService.cs:line 180
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
   at System.Threading.QueueUserWorkItemCallback.<>c.<.cctor>b__6_0(QueueUserWorkItemCallback quwi)
   at System.Threading.ExecutionContext.RunForThreadPoolUnsafe[TState](ExecutionContext executionContext, Action`1 callback, TState& state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
   at System.Threading.Thread.StartCallback()
An unhandeled Exception has occoured. DMXControl 3 Kernel has to be terminated. Press Enter to exit.

Ich habe den Schweregrad im Übrigen deswegen hoch gesetzt, da sich der Kernel potentiell beenden kann (zumindest gemäß des Wortlauts der letzten Zeile).

In der Beta 7 kann das Position Master Node nicht geladen werden, sobald es in einem Graphen verwendet wird.

Das unten beigefügte Projekt ist neu erstellt. Dort habe ich den Position Master 1 nur im Position Master Node einem sonst leeren Graphen hinzugefügt. Beim erneuten Laden des Projekts generiert der Kernel die nachfolgende Fehlermeldung und im Graphen wird der Node entfernt.

09:58:09 WARN  InputManager - Unable to add Node to Graph: 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.Input.v2.Worker.PositionMasterNode.setInputaValue() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 192
   at org.dmxc.lumos.Kernel.Input.v2.Worker.PositionMasterNode.setParameterInternal(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\Wrapper\Master\PositionMasterNode.cs:line 389
   at org.dmxc.lumos.Kernel.Input.v2.AbstractNode.setParameter(GenericParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\Graph\Node\AbstractNode.cs:line 371
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree, Func`2 convertName, Func`3 convertStringValueToID, Func`3 convertObjectValueToID) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 341
   at LumosLIB.Tools.ParameterTools.LoadParameters[TParameter](IParameterable`1 parameterable, ManagedTreeItem tree) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\ParameterTools.cs:line 228
   at org.dmxc.lumos.Kernel.Input.v2.InputManager.CreateSavedNode(ManagedTreeItem n, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Input\v2\InputManager.cs:line 0

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

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

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

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.

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.

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.

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.

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.

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.

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.

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%

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.

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.

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.

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.

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.

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.

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.

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.

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.