Bugtracker DMXControl 3

Wie im beigefügten Screenshot zu sehen, sollte es sinnvoll sein, wenn die Cuelists des aktuellen Projekts im Fenster “Choose a cuelist” alphabetisch sortiert werden würden.

Sollte für die Realisierung dieses Wunsches ein Beispielprojekt der aktuellen Situation benötigt werden, bitte ich um entsprechende Info.

Ich habe im beigefügten Projekt eine einfache Cuelist erstellt, die einem Cuelist-Track einer Timecode-Show zugeordnet ist.

Editiere ich eine beliebige Cue aus dieser Cuelist im Programmer und speichere die Änderungen zum Beispiel Replace oder Update zurück, wird der Wert für den Trigger immer auf 00:00:01.000 zurückgesetzt und die Cue an Position in der Cuelist eingefügt.

Die zugehörigen Logs beinhalten folgende Schritte:

1. Sitzung starten und Projekt laden
2. Cue 3 der Cuelist 1 in den Programmer laden
3. Änderungen vornehmen
4. Änderungen über Update in die Cue 3 zurückspeichern
5. Cue 3 an ursprüngliche Position zurückschieben und alten Wert manuell wieder eintragen
6. Projekt speichern und Projekt beenden

Mit der Beta 9 hat sich die Reihenfolge der Einträge im Project Explorer geändert. Aktuell

• findet sich der Eintrag “Macro Board Profiles” an oberster Position im Project Explorer wieder
• ist der Eintrag “Softdesk” der vorletzte Eintrag.

Wenn ich in die älteren Versionen schaue, dann sollte folgende Reihenfolge die passende sein

1. Cuelists
2. Cuelist Groups
3. Devices
4. Device Groups
5. Presets
6. Files
7. Item Lists
8. Electricity
9. Timecode Shows
10. Macros
11. Master
12. Executor Pages
13. Softdesks
14. Macro Board Profiles
15. Stage Views
16. Layouts
17. Project Settings

Möchte ich diverse Master in verschiedenen Gerätefunktionen nutzen, so ist dies bei folgenden nicht mehr möglich:

• ParameterMaster: alle Varianten von Index (Index allgemein, Goboindex, Prismindex)
• SpeedMaster: Strobe, alle Varianten von Rotation (Rotation allgemein, Goborotation, Prismrotation)

In DMXControl 3.2.3 können die Master auf die genannten Funktionen angewendet werden, wie es auch im Wiki im Master beschrieben ist.

Getestet habe ich dies mit dem Clay Paky QWO 800 sowie dem Futurelight DMH-160. Logs kann ich nicht zur Verfügung stellen, da keine kontextbezogenen Ereignisse protokolliert wurden. Es erscheint einzig und allein der Tooltip “Value not valid”.

Ich habe in einem DDF folgenden Code, um ein rotierbares Objekt mittels “index” zu positionieren und mittels “rotation” zu drehen. Dabei möchte ich über das Attribut “defaultval” für jede Funktion einen bestimmten Startwert mitgeben.

<index dmxchannel="0" defaultval="0">
  <range range="60" mindmx="0" maxdmx="100" minval="0" maxval="60"/>
</index>
<rotation dmxchannel="1" defaultval="4">
  <step type="stop" mindmx="0" maxdmx="0"/>
  <range type="cw" mindmx="194" maxdmx="134" minval="0.05" maxval="5"/>
  <range type="ccw" mindmx="195" maxdmx="255" minval="0.05" maxval="5"/>
</rotation>

Trotz der gezeigten Definition wird das Attribut “defaultval” ignoriert und folglich nicht wie erwartet der DMX-Wert 0, sondern der DMX-Wert 50 für DMX-Kanal 1 und DMX-Wert 0 für DMX-Kanal 2 ausgegeben.

Das Problem besteht sowohl in DMXC 3.2.3 als auch noch in DMXC 3.3.0 Beta 3.

Ändere ich den Namen für die Elemente eines Makros oder aus dem Softdesk, so wird der Name nur im Input-Baum und Output-Baum direkt aktualisiert. Die Inputs und Outputs in den Graphen selbst behalten den Namen bei.

Die neue WPF-Message-Box kann aktuell noch in ihrer Größe angepasst. Dabei ist auch ein Maximieren möglich, wenn ich das Fenster an den Bildschirmrand ziehe. Dies sollte aber unterbunden werden und die WPF-Message-Box sollte eine ggf. global vorgegebene Größe erhalten.

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.

Beim Laden eines Projekts konnte eine Cue in einer Cuelist nicht richtig geladen werden. In der zugehörigen Fehlermeldung wird der Name der Cue mitgeteilt, jedoch aber nicht die Cuelist (in Klartext), die die fehlerhafte Cue enthält.

Nachfolgend hierzu der Auszug des Logs aus der Beta 8.

22:12:39 WARN  ProjectManager - Error when loading Project Clubset 2.3: Warnings in Project
org.dmxc.lumos.Kernel.Exceptions.ProjectIOException: Warnings in Project
   at org.dmxc.lumos.Kernel.Resource.LumosIOContext.ThrowOnWarnings() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\LumosIOContext.cs:line 238
   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 461
22:12:39 WARN  ProjectManager - Loading Cue Lists in Project
22:12:39 WARN  ProjectManager - Error loading complete Scene Step 1. There could be a loss of information! in Step 1

Ich wollte für einen Test das Projekt aus  FS#5039  über die Import-Funktion importieren. Es war damit noch nie in meinem ProjectStore enthalten. Der Import des Projekts schlägt scheinbar auf Grund von folgender Fehlermeldung im Kernel fehl:

21:01:22 ERROR Project_gService - Error in Project Import
System.IO.DirectoryNotFoundException: Could not find a part of the path 'D:\Arbeit\MSK event GbR\Software\DMXControl 3.3.0\Kernel\ProjectStore\WCH60S11_Betatest_Positionmaster\Autosave\2.0.2.dmz'.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at Lumos.ProjectStore.ProjectStore.ImportProject(Stream inputStream, Boolean createNewOnDuplicate, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos.ProjectStore\ProjectStore.cs:line 272
   at org.dmxc.lumos.Kernel.Project.ProjectManager.ImportProject(Stream inputStream, Boolean createNewOnDuplicate, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 195
   at org.dmxc.lumos.Kernel.Net.gService.Project_gService._importProject_RequestReceived(Object sender, RequestEventArgs`1 e) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Net\gService\Project_gService.cs:line 419

In der GUI wurde hier eine entsprechende äquivalente Fehlermeldung angezeigt, die ebenfalls für sich genommen suggeriert, als ob der Import fehl geschlagen wäre.

Tatsächlich wird der Import des Projekts trotz dieser Fehlermeldung doch erfolgreich abgeschlossen und im Explorer im ProjectStore-Verzeichnis das benötigte Verzeichnis angelegt. Nach einem erneuten Öffnen der Project Administration wird mir das Projekt dann auch in der Liste der Projekte aufgeführt und ich kann zumindest den Versuch starten, es zu öffnen.

Aktuell besteht eine Inkonsistenz bei der Angabe der Wiedergabezeit zwischen Timecode-Player und den Timecode-Triggern in der Cuelist. Da im Timecode-Player die Angabe mit tausendstel Sekunden und im Timecode-Trigger in der Cuelist mit 25 FPS erfolgt, kann ich die aktuelle Position des Wiedergabe-Markers nicht 1:1 manuell in den Timecode-Trigger übertragen.

Daher wären folgende Dinge zu überlegen:

* Wird das Anzeige-Format im Timecode-Player auf die 25FPS-Variante geändert oder

• wird der Timecode-Trigger wird mit tausendstel Sekunden angegeben?

Einer der beiden Punkte sollte umgesetzt werden, damit auch die Nachvollziehbarkeit erhöht wird.

Ich möchte die Verknüpfungen zu den einzelnen Anwendungen von DMXControl 3 im Startmenü gerne vom Installer im folgenden Pfad ablegen lassen:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.3.0\

Dass es sich hier nun um das Verzeichnis für alle Benutzer handelt, sei erstmal irrelevant, weil ich dies ja nicht explizit festlegen kann.

Scheinbar auf Grund der existierenden Registry-Einträge für die ebenfalls auf meinen PCs installierte 3.2.3 schlägt der Installer der 3.3.0 immer folgenden Pfad vor:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DMXControl 3.2.3\

Egal ob ich den Pfad auf meinen Wunschpfad ändere (im Installer trage ich ja dann nur “DMXControl 3.3.0” ein) oder ich sage generell, dass der Installer bitte keine neuen Verknüpfungen anlegen soll - in beiden Fällen landen alle Verknüpfungen im Startmenü immer im “alten” Verzeichnis, also im Verzeichnis “DMXControl 3.2.3”.

Im Anhang die Log-Datei des Installers.

Bei der Bearbeitung des Tickets bitte beachten, dass im QRM22.1 grundlegende Anpassungen am Installer beschlossen wurden, welche bis zum Release auch umgesetzt werden sollen. Hierzu gehören unter anderem die Tickets FS#2763 und FS#4708.

Das Dirty Flag berücksichtigt aktuell keinerlei Änderungen etc., die in einem Softdesk vorgenommen werden. Dies umfasst unter anderem:

• Hinzufügen neuer Controls, selbst obwohl diese im Input bzw. Output-Baum des Input Assignments auftauchen
• Anpassung des Display Names
• Festlegen von Position und Größe
• Auswahl des Styles
• Änderung des Layouts wie Farbe oder auch des Textes

An dieser Stelle müssen wir aber aufpassen, dass ja über das Input Assignment Teile der Softdesk Controls zur Laufzeit geändert werden können. Hier müssen wir festlegen, ob:

• durch eine Änderung über das Input Assignment initiierte Änderung von Text und / oder Farbe grundsätzlich das Dirty Flag triggert, weil es per Definition eine Änderung am Control ist (analog zu den Werten für Master und Executoren).
• per se Anpassungen an Farbe und Text ignoriert werden, das heißt auch, wenn keine Ansteuerung über das IA erfolgt und man diese manuell im Softdesk Editor vornimmt.
• das Dirty Flag nur getriggert wird, wenn Änderungen im Edit-Modus des Softdesks erfolgen (dabei ist dann egal ob per IA oder manuell). Erfolgen Änderungen an Farbe etc. im Anzeige-Modus, werden diese ignoriert.

Um hier mal ein bisschen zu spielen, kann das kleine Projekt aus Ticket  FS#4739  verwendet werden.

Ich hatte im beigefügten Projekt ursprünglich zwei Cuelists angelegt. Die Cuelist 2 hatte ich dabei per Special Cue in die Cuelist 1 referenziert. Die Cuelist 1 enthält neben der Special Cue mit der Referenz zur Cuelist 2 noch zwei weitere “einfache” Cues.

Nun habe ich die Cuelist 2 aus dem Projekt gelöscht und das Projekt gespeichert. Die Special Cue in der Cuelist 1 ist aber weiterhin vorhanden.

Beim erneuten Laden des Projekts wird zwar logischerweise ein Fehler ausgeworfen, dass die Cuelist 2 fehlt und die Referenz entsprechend nicht aufgelöst werden kann. Jedoch im gleichen Zusammenhang der Inhalt der gesamten Cuelist 1 auf den ersten Blick scheinbar nicht mehr geladen. Die Cuelist 1 hat dann 0 Cues. Der Kernel wirft hierbei den folgenden Fehler aus:

07:47:42 WARN  ProjectManager - Error when loading Project 2022-04-27 - Cuelist reference.dmz: Warnings in 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.loadProject(String filename, Stream inputStream, Boolean loadId, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:Zeile 384.
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2
07:47:42 WARN  ProjectManager - Loading Cue Lists in Project
07:47:42 WARN  ProjectManager - Error loading complete Scenelist Cuelist 1. There could be a loss of information! in Cuelist 1
07:47:42 WARN  ProjectManager - A Cuelist with the ID 70ff8bf9-eb8c-4f62-8ae5-65370c96d2b3 doesn't exist in Go: Cuelist 2

Füge ich der Cuelist 1 dann im Nachgang noch eine weitere Cue hinzu, wird deren Inhalt aktualisiert und es tauchen die bereits existierenden wieder auf. Auch der Project Explorer berichtigt die Zahl der in der Cuelist 1 enthaltenen Cues. Alternativ kann ich das Projekt durch manuelles Handanlegen an der Datei Scenenlists.xml wieder ohne Fehlermeldung vollständig zum Laufen bekommen, indem ich dort den zugehörigen Eintrag zur Special Cue entferne.

Im Hinblick auf die Zusammenfassung dieses Tickets, würde ich folgende alternativen Erwartungshaltungen formulieren, um das Problem zumindest dahingehend zu lösen, als dass mir nicht die gesamte Cuelist 1 um die Ohren fliegt:

• Bereits beim Löschen einer Cuelist wird geprüft, ob diese ggf. per Special Cues in anderen Cuelists referenziert ist. Ist dem so, erscheint wie beim Löschen von Geräten oder Gerätegruppen der Reference Manager, wo ich zum einen auf diesem Umstand hingewiesen werde und zum anderen festlegen kann, ob ich die zu löschende Cuelist referenzierenden Special Cues komplett löschen möchte.
• Beim Laden des Projekts bietet mir die “Fehlerbehebung” an, die defekten Special Cues zu löschen anstelle den Fehler nur zu ignorieren. Hierbei wird effektiv gesehen der Schritt nach einer Bestätigung entsprechend vom Programm ausgeführt, den ich wie beschrieben manuell vorgenommen habe.

Zur Nachtverfolgung habe ich das defekte Projekt beigefügt. Da der Eintrag im Kernel eindeutig ist, verzichte ich auf das beifügen weiterer Log-Dateien.

Ich habe das Projekt aus  FS#5180  weitergebaut und in eine Timecode Show überführt.

Führe ich die Timecode Show erstmalig nach dem Laden des Projekts aus, läuft diese bis zum Ende der Release Time wie erwartet ab. In dem Moment, wo der Marker wieder auf 0 springt (weil die sich Cuelist beendet hat), wird der Inhalt der Cue 2 wiedergegeben. Führe ich dann die Timecode Show erneut aus, wird die Cue 1 vollständig ignoriert und nur der Release der Cuelist ausgeführt.

Die Erwartungshaltung ist, dass nach dem automatischen Beenden der Cuelist (Release when last cue ends) und dem Zurücksetzen des Markers die Cuelist wie nach dem Laden des Projekts (oder dem manuellen Stoppen) aus ist und ich die Timecode Show vollständig wiedergeben kann.

Hätte ich als Release Mode “manual only” gewählt, dann wäre das aktuelle Verhalten in Ordnung.

Ich habe das Projekt aus  FS#5181  nun im Bereich der Zeiten von Cues und der Cuelist weiterbearbeitet. Nun ist die Cuelist kürzer als die Audiodatei. Wie im Ticket  FS#5181  soll sie sich aber über “Release when last cue ends” selbst beenden.

Führe ich die Timecode Show das erste Mal nach dem Laden des Projekts aus, läuft diese auch wie gewünscht ab. Auch wird sie mit dem Zurücksetzen des Markers auf 0 nicht erneut in Teilen ausgeführt.

Starte ich die Timecode Show ein zweites Mal, wird ausschließlich die Audio-Datei wiedergegeben. Die Cuelist selbst bleibt “dunkel”. Der Kernel wirft dabei folgende Fehlermeldung:

17:34:13 ERROR Timecode -
org.dmxc.lumos.Kernel.Exceptions.KernelPanicException: WTF
   at org.dmxc.lumos.Kernel.Scene.RealtimeTimestamp.initialize() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\RealtimeTimestamp.cs:line 104
   at org.dmxc.lumos.Kernel.Scene.RealtimeTimestamp.reset() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\RealtimeTimestamp.cs:line 90
   at org.dmxc.lumos.Kernel.SceneList.AbstractSceneContainer.resetTimestamp() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\AbstractSceneContainer.cs:line 89
   at org.dmxc.lumos.Kernel.SceneList.SceneList.play() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 986
   at org.dmxc.lumos.Kernel.Timecode.CuelistTrack.<>c__DisplayClass26_0.<proccessNextFrame>g__feed|7(IEnumerable`1 scenelistTimeslots, Boolean triggerPlay) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\CuelistTrack.cs:line 199
   at org.dmxc.lumos.Kernel.Timecode.CuelistTrack.proccessNextFrame(Int64 tick) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\CuelistTrack.cs:line 0
   at org.dmxc.lumos.Kernel.Timecode.Track.ProcessNextFrame(Int64 tick) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Tracks\Track.cs:line 191
   at org.dmxc.lumos.Kernel.Timecode.Timecode.<>c__DisplayClass139_0.<processNextFrame>b__4(ITrack t) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 1109
   at LumosLIB.Tools.CommonTools.ForEach[T](IEnumerable`1 source, Action`1 action, Boolean parallel) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:line 598
   at org.dmxc.lumos.Kernel.Timecode.Timecode.processNextFrame() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Timecode\Timecode.cs:line 1095

Die Erwartungshaltung ist, dass ich an dieser Stelle die Timecode Show ebenfalls mehrfach wiedergeben kann, selbst wenn die Cuelist kürzer als die Audio-Datei ist. Wie aktuell schon der Fall muss die Audio-Datei aber bis zum Ende wiedergegeben werden.

Im Anhang sind das angepasste Projekt sowie die Log-Dateien zu finden.

Füge ich eine zweite Audiodatei dem Audio-Track hinzu, so wird diese bei 0:00 positioniert. Dies hat dann zur Folge, dass ich die bereits im Audio-Track existierende Audiodatei nicht mehr verschieben kann.

Erst wenn eine bereits vorhandene Audiodatei so weit nach hinten geschoben habe, kann ich beide Audiodateien einzeln wieder verschieben. Aus diesem Grund sollten neue Audiodateien immer hinter die letzte Audiodatei eingefügt werden.

Füge ich eine Special Cue ein, so wurde die in DMXControl 3.2.3 standardmäßig so benannt, welche Aktion beim hinzufügen dieser Special Cue eingestellt war. Zum Beispiel:

• Audio: Play: Jack Ü - to ü [vs. Skrillex & Diplo feat. AlunaGeorge].mp3
• Cuelist: Go: DMH EFF laufend 4-fach

In DMXControl 3.3.0 Alpha 9 werden aktuell stattdessen die Namen vergeben, welche in den Optionen der Cuelists voreingestellt sind.

Aus meiner Sicht sollte die Zeit für das automatische Schließen der Abfrage “Load last window layout?” verlängert werden. Gerade wenn ich größere Projekte lade, ist DMXControl 3 noch lange mit sich selbst beschäftigt. In diesem Zustand geht die Abfrage ein Stück weit darin unter, weil im Hintergrund noch vielerlei Dinge passieren.

Ich habe ein Projekt geladen, in dem verschiedene Geräte deaktiviert sind. Aktiviere ich diese Geräte nun, kann ich diese nicht direkt sauber ansprechen. Dies äußert sich unter anderem darin, dass beim Leeren des Programemrs werden die Intialwerte nicht richtig gesetzt, wie z. B. Dimmer auf 0, Shutter geschlossen oder Standardfarbe weiß. Teilweise bleiben auch beim Beenden von Cuelists die Werte in einem undefinierten Zustand hängen.

Erst wenn ich das Projekt noch einmal neu lade, reagieren die wieder aktivierten Geräte so wie gewohnt.

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 QRM 22.3 wurde festgelegt, dass Cuelists mit Audio Cues grundsätzlich weiter existieren sollen. Einzig die Funktion, dass die Audio cue an die entsprechende Cuelist einen Timecode zurück gibt, wird entfernt. Siehe hierzu die Kommentare in  FS#4755 .

Ich habe in dem beigefügten Projekt nun eine Cuelist, die aus einer Audio cue und drei Licht cues besteht. Für ich die Cuelist aus, wird einzig die Audio cue wiedergeben. Alle nachfolgenden (Licht) Cues werden nicht ausgeführt, ob hier follow-Trigger hinterlegt sind.

Die Erwartungshaltung ist auf Basis des genannten Beschluss, dass die Cuelist eben vollständig bis zur letzten Cue ausgeführt wird.

Möchte ich im Add Device Dialog die DMX-Adresse für ein neu zu patchendes Gerät korrigieren und lösche mittels der Backspace-Taste oder der Entf-Taste meine Eingabe, so werden immer zwei Zeichen entfernt. Im Eingabefeld für Device Name tritt dieses Phänomen nicht auf.

Da dieses Problem ein reines GUI-Problem ist, kann ich hierzu keine Logs zur Verfügung stellen. Dies muss daher direkt in der Software nachvollzogen werden.

Ich habe ein neues Projekt mit zwei kleinen Connectionsets angelegt, dieses gespeichert, geschlossen und dann wieder neu aufgerufen.

Wechsele ich in die Graphenansicht, gibt der Umbra in regelmäßigen Abständen die folgende Fehlermeldung aus. Sobald ich wieder in die Tabellenansicht zurückgehe, ist alles “ruhig”.

19:22:15 ERROR BidirectionalStreamBridgeWithResponseFilter - Request Listener ConnectionSetProcessed has faulted.
System.IO.IOException: The client reset the request stream.
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2MessageBody.ReadAsync(CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Grpc.AspNetCore.Server.Internal.PipeExtensions.ReadStreamMessageAsync[T](PipeReader input, HttpContextServerCallContext serverCallContext, Func`2 deserializer, CancellationToken cancellationToken)
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
   at Grpc.AspNetCore.Server.Internal.HttpContextStreamReader`1.<MoveNext>g__MoveNextAsync|9_0(ValueTask`1 readStreamTask)
   at Grpc.Core.AsyncStreamReaderExtensions.ReadAllAsyncCore[T](IAsyncStreamReader`1 streamReader, CancellationToken cancellationToken)+MoveNext()
   at Grpc.Core.AsyncStreamReaderExtensions.ReadAllAsyncCore[T](IAsyncStreamReader`1 streamReader, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__0>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 60
--- End of stack trace from previous location ---
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__0>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 60

Die Fehlermeldung kann ich gut mit dem beigefügten Projekt reproduzieren, indem ich in einem der beiden Graphen anfange, die Nodes zu verschieben - spätestens, wenn ich das im zweiten Graphen mache.

Ich habe in einem Projekt ein Connectionset erstellt und dieses Projekt dann gespeichert. Danach öffne ich dieses Projekt wieder und klone den Graphen.

Ersetze ich nun innerhalb dieses Graphens per Drag & Drop die In- bzw. Output, werden mir die neuen In- bzw. Outputs sowohl im Graphen als auch in der Tabelle nicht angezeigt. Auch bei einem erneuten Ladend des Projekts erfolgt keine Aktualisierung des Namens. Die gewünschte, nach dem Klonen geänderte Zuordnung funktioniert aber.

Beispielprojekt kann bei Bedarf nachgereicht werden,

Werden die Angaben im Informations-Teil des DDFs wie folgt formatiert, zerschießen diese das Add Device Dialog entsprechend des beigefügten Screenshot.

<information>
  <ddf-library-id>
    
    </ddf-library-id>
  <model>
        Super Winner HID
    </model>
  <vendor>
         JB Systems
    </vendor>
  <author>
       cooltour
    </author>
  <mode>
       5CH
    </mode>
  <electrical>
    <static>250</static>
  </electrical>
  <comment>
    </comment>
</information>

Da wie zu sehen das DDF auch nicht unter der Gerätebezeichnung oder dem Hersteller erscheinen, sollte über eine der beiden folgenden Szenarien zum Abfangen dieses Problems nachgedacht werden:

• Im Informations-Teil der DDFs dürfen die Tag für model, vendor etc. nur in einer Zeile liegen. Falls nicht, wird das DDF als ungültig gekennzeichnet.
• Im Fenster selbst wird eine entsprechende Robustheit eingebaut, dass solche Dinge zu keinem Problem bei der Anzeige mehr führen.

Das DMXC-Mixer-Node hat auf der Output-Seite aktuell nur den Output “Device”, in dem die Device-ID angezeigt wird. Hier sollten aus Konsistenzgründen noch die Outputs “Name” und “Number” hinzugefügt werden, so wie es bei vielen anderen Wrapper-Nodes der Fall ist.

Dem entsprechend würden die ersten drei Outputs wie folgt lauten:

• (Device-) Name
• (Device-) ID
• (Device-) Number

Ich habe ein Projekt gespeichert, wo der Timecode-Player geöffnet ist. Lade ich das Projekt und bestätige, dass das letzte Fensterlayout geladen werden soll, bleibt der Inhalt des Timecode-Players leer.

Ich habe mit der Beta 10 ein neues Projekt erstellt und einen einzigen Graphen gebaut, der insgesamt 11 Nodes und 6 In- bzw- Outputs umfasst. Verschiebe ich nun eines der sechs Compare-Nodes, steigt der Datenverkehr im DMXC-Netzwerk massiv an. Es werden gemäß GUI rund 3.000 Nachrichten übertragen, die eine Auslastung von rund 6 MB/s generieren. Das führt auch dazu, dass das Verschieben selbst nicht mehr flüssig abläuft. Auch die Funktion “Auto position” stockt und positioniert die Nodes nicht mehr richtig.

Dieses Problem ist aber gefühlt eher neueren Datums. Genauer eingrenzen kann ich dies später.

Im Anhang findet sich das entsprechende Projekt, ein Screenshot und die zugehörigen Logs.

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 füge in einem neuen leeren Projekt das Draw Bitmap Node ein und ändere die Schriftart von “Courier New” auf “Arial”. Diese Änderung wird vom Node zwar angenommen, aber nicht umgesetzt. Auch ein Speichern und Neuladen des Projekts hilft hier nicht.

Klappe ich den Eintrag “Font” in den Einstellungen des Nodes auf, steht dort in jeder Zeile die folgende Fehlermeldung:

Der Typ "System.Drawing.FontConverter" in der Assembly "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" konnte nicht geladen werden.

Dieser Eintrag taucht in keinem der Logs auf, daher nur der Screenshot.

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

Nach der Implementation des Tickets ??? öffnet sich die die Project Administration nun automatisch nach dem Start von DMXC 3.3, sobald zwischen GUI und Kernel eine Verbindung aufgebaut ist.

Es ist allerdings möglich, dass ich die Project Administration nach dem Start der GUI bis zur Herstellung der Verbindung zum Kernel ebenfalls direkt aus der GUI öffne. Ist die Verbindung dann aufgebaut, wird die Project Administration ein zweites Mal durch den oben beschriebenen Automatismus geöffnet. In diesem Fall ist die Project Administration also zweimal geöffnet.

Im Idealfall sollte dies abgefangen werden, weil unter Umständen die Gefahr besteht, dass das zweite Fenster im Hintergrund liegt und man die Software nicht weiter bedienen kann. Auf alle Fälle ist es so, dass die zweite Project Administration geöffnet bleibt, sobald der Ladevorgang vom Laden eines Projekts über die zuerst geöffnete Project Administration abgeschlossen ist.

Ich habe den Chaser auf eine Gruppe von 10 Geräten gezogen und den Play Mode auf “Random” gesetzt. Wähle ich bei “Size” einen Wert, der der Anzahl der Geräte dieser Gruppe entspricht oder darüber hinaus geht - im aktuellen Beispiel also >= 10 - hängt sich der Chaser mit folgender Fehlermeldung auf:

20:14:36 WARN  SceneFadeTicker+TickerParallelBag - Exception triggering Item: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.RandomChaserPattern.GetNextIndex(Int32 deviceCount) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\RandomChaserPattern.cs:line 61
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.RandomChaserPattern.GetNextStep(Int32 deviceCount, Int32 length) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\RandomChaserPattern.cs:line 25
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.Chaser.AbstractChaserPattern.doUpdateChaser(Int64 timeInMs, Int64 delta, Int32 duration, Int32 fadetime, Int32 deviceCount, Int32 length, Int32 stepSize, Int32 breakSteps, Int32 breakTime) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\Pattern\AbstractChaserPattern.cs:line 69
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.ChaserFilter2.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\Chaser\ChaserFilter2.cs:line 215
   at org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:line 47
   at Lumos.Kernel.Scene.Entry.FilterAdapter.PropertyValueFilterRuntimeDecorator.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Entry\FilterAdapter\PropertyValueFilterRuntimeDecorator.cs:line 103
   at org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:line 401
   at org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:line 367
   at org.dmxc.lumos.Kernel.Scene.Fade.FadeDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:line 94
   at org.dmxc.lumos.Kernel.Scene.Delay.DelayDecorator.setOutputTime(Int64 timeInMsAbs, Double delayPercent, Double fadePercent, Boolean fadeIn, IMixerRegister register, IProcessable fader) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:line 41
   at org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:line 35
   at org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:line 205
   at org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:line 91
   at org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.TickerParallelBag.processBag(ProcessableTickerBag bag, Int64 now) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:line 350

Ich starte eine Timecode-Show über Play und halte die Show mittels Pause an. In dieser Situation kann ich den Wiedergabe-Marker (den roten) nicht neu positionieren.

Der Wiedergabe-Marker lässt sich daher nur unter einer ganz bestimmten Konstellation neu positionieren und zwar:

• Die Wiedergabe wurde nicht durch pausieren angehalten.
• Nach dem Pausieren wird der Track nochmals vom ursprünglichen Startpunkt wiedergegeben.
• Die Wiedergabe wird über Stop angehalten.

Wenn diese Punkte beachtet werden, kann man zwar damit arbeiten, jedoch ist es ein unerwartetes Verhalten, was den Workflow beeinträchtigt.

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.

Ist die Anzahl der Geräte im Ordner Devices oder in einer Device Group so groß, dass man in dem Ordner scrollen muss, wird bei einer Verlängerung der Gerätebezeichnung immer nur die Länge der Zeichenkette als Referenz genommen, die sich im sichtbaren Teil der Liste befindet. Haben Geräte im unteren Teil der Liste eine (deutlich) längere Bezeichnung, so wird diese nicht vollständig angezeigt - obwohl die Spalte Name diese längere Bezeichnung zum Teil bereits registriert.

Im Anhang ist ein entsprechendes Beispielprojekt zu finden.

Ich habe im beigefügten Projekt zwei uelists mit mehreren beatgesteuerten Cues, denen ich ihre eigenen SpeedMaster zugeordnet habe. Lerne ich den neuen BPM-Wert an - egal ob über Input Assignment via Tastatur-Taste “L” oder direkt im Master-Fenster - bleibt die interne Ausgabe des Beatsignals stehen, bis ich mit dem Lernen durch bin.

Dieses Problem sieht optisch blöd aus und ist (offenbar) mit der Implementierung des Multimedia-Timers (wieder) entstanden (siehe unter anderem Commit 6eaf309459 und ggf. auch 225677e07d). Unter anderem die Beta 6 zeigte dieses Verhalten nicht, sodass die beatgesteuerteren Cues während des Learn weiterliefen.

Zum Nachvollziehen das Projekt öffnen, die Taste G zum Starten der beiden Cuelists drücken und dann den Beat über L anlernen bzw. über S synchronisieren.

Siehe Titel

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.

Wie im beigefügten Screenshot zu sehen, fällt die Fehlermeldung “Nur Timecode-Trigger in Cuelist-Track erlaubt” aktuell sehr technisch aus. Hier sollte der Hinweistext nochmal dahingehend bereinigt werden, dass er als “normaler” Fließtext zu lesen ist.

Lade ich die Cue 4 aus der Cuelist “Ambient” im beigefügten Projekt in den Programmer, kann ich nach einem kurzen Moment die gesamte GUI nicht mehr bedienen. Selbst das Stoppen der Cuelist kann nicht mehr umgesetzt werden.

Sobald ich das Art-Net-Plugin selbst manuell abschalte oder der Kernel es beim Herunterfahren automatisch abschaltet, erscheint im Log immer der folgende Eintrag.

17:51:13 ERROR ArtNetFactory -
System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   bei System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   bei org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\mos_DMXPlugins_Pipeline_master_2\ArtisticLicenseArtNet\src\ArtNetManager.cs:Zeile 704.

Aktiviere ich es danach wieder, arbeitet es soweit auch wie erwartet. Die Meldung erweckt jedoch gerade beim Überprüfen der Einstellungen den Eindruck, als ob etwas kaputt ist.

Wenn ich im folgenden Setup auf PC 1 in einem leeren Projekt Geräte und Gerätegruppen in einer Stage View hinzufüge, so wird die auf PC 2 nicht aktualisiert. Gleiches gilt umgekehrt.

• PC 1: Umbra, Kernel, GUI
• PC 2: GUI

Auch wenn die Icons der Geräte und Gerätegruppen nicht simultan anzeigt werden, so aktualisieren sich zumindest beide GUIs, wenn die Geräte auswähle.

Die neuen Executoren unterstützen aktuell noch keine Multi-Touch-Eingabe. Diese Funktion soll auch Basis der Implementierung im Softdesk übernommen werden.

Beim Reproduzieren des Fehlers aus Ticket  FS#4709  habe ich ein einziges DDFs aus verschiedenen Verzeichnissen einem neuem Projekt hinzugefügt. Bedeutet:

1. DDF aus Verzeichnis A dem Projekt hinzugefügt
2. DDF in ein anderes Verzeichnis verschoben und leicht modifiziert
3. DDF aus Verzeichnis B dem Projekt hinzugefügt
4. …

Aus diesem Grund befand sich das DDF beim Speichern des Projekts nicht mehr im Verzeichnis A. Dies bemerkt der Kernel und trägt eine Fehlermeldung im Log ein:

23:43:06 WARN  FileBackendDatastore - Following Resources could not be saved in Project:
{ "type": "DDF", "name": "Icons\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
{ "type": "DDF", "name": "Images\\Eurolite LED BAR-6 QCL RGBA (9 channel).xml" }
23:43:07 INFO  Messages - Message from SKI-DSK-TCM900A: Saved Project to GUI SKI-DSK-TCM900A, Path 2022-01-22 - DDF Folders.dmz

In der GUI gibt es dazu keinerlei Hinweise, dass beim Speichern des Projekts nicht (mehr) alle benötigen Daten gefunden werden konnten. Gerade in Hinblick darauf, wenn zukünftig noch mehr Dateien für das Projekt benötigt werden, sollte bereits beim Speichern ein solcher Hinweis erscheinen.

Möglicherweise steht dieses Ticket ein Stück weit auch im Zusammenhang mit  FS#4651  oder kann im gleichen Aufwasch behoben werden.

Das beigefügte Projekt kann insofern nicht vollständig geladen werden, als dass die entsprechend zugeordneten Executoren mit ihren Einstellungen nicht geladen werden. Die Bänke sind vorhanden, aber ohne gefüllte Executoren. In den Logfiles sind zahlreiche Einträge zu finden.

Das ursprüngliche Projekt habe ich dabei nur in DMXC 3.3 Beta 2 importiert und aufgerufen. Neu gespeichert wurde es mit der 3.3 nicht.