Bugtracker DMXControl 3

Für den Position Master sollen folgende Buttons hinzugefügt werden:

• Zero Pan
• Zero Tilt

Für einen Test baute ich kürzlich zusätzlich zum Main-PC noch einen zweiten Backup-PC auf, wovon nur einer der beiden PCs die DMX-Daten über Art-Net ausgeben sollte. Gerade bei Art-Net gibt es ja bekanntermaßen murks, wenn zwei PCs das gleiche Gerät ansprechen wollen.

Wenn alles geregelt läuft, kann ich vor einem Neustart zum Beispiel die Art-Net-Ausgabe deaktivieren. Liegt aber nun ein Fehler vor, wodurch ich das Deaktivieren nicht mehr entsprechend anstoßen kann, sind die DMX-Interfaces wie zuletzt gespeichert beim erneuten Starten des Kernels nur kurze Zeit wieder aktiviert und die Ausgabe wird auf 0 gesetzt - egal ob ein Projekt geladen wurde oder nicht. Dies war im konkreten Fall insofern problematisch, weil das Projekt beim Starten von DMXControl 3 als “Default Project” direkt mit geladen wird und ich während des Ladevorgangs keinen Zugriff auf die DMX-Ausgabe habe. Damit mir nun mein Main-PC nicht in die Suppe spuckt und nichts ausgegeben wird, blieb mir nichts anderes übrig, als im Interface-Rack die Art-Net-Interfaces händisch temporär direkt auf den Backup-PC umzuklemmen.

Um nun im Falle eines unvorhergesehen Neustarts (insbesondere mit einem Default Project, was effektiv gesehen das “Arbeitsprojekt” / “Showprojekt” ist) nicht Hand an der Verdrahtung der Hardware anlegen zu müssen, würde ich mir hier eine Möglichkeit wünschen, dass ich im Idealfall selbst den Zeitpunkt festlegen kann, wann die DMX-Ausgabe auf die Interfaces bzw. die Interfaces selbst aktiviert werden - und zwar unabhängig davon, was in den Einstellungen für die DMX-Ausgabe grundsätzlich gespeichert ist.

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.

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.

s.o.

Ich habe gestern mit meinem Live-Show-Projekt über einen längeren Zeitraum ein wechselndes Ambiente gebaut und zwischendurch immer mal wieder Licht live gedrückt. Beim Heraussuchen der Logdateien für einen anderen Fehler bin ich auf die mit rund 170 MB sehr große Logdatei des Kernels aufmerksam geworden.

Der folgende Eintrag wurde über den genannten Zeitraum über 1,2 Millionen Mal in die Logdatei geschrieben - sogar noch als vorletzter Eintrag bevor der Kernel final geschlossen wurde.

2023-01-06 19:31:14,781 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 11 elements
[...]
2023-01-06 22:50:18,081 [114] DEBUG org.dmxc.lumos.Kernel.Input.v2.InputManager - Processing Queue of Graphs contains 50 elements
2023-01-06 22:50:18,095 [Main] INFO  DMXControl 3 Kernel - Kernel closing!

Diese Logeinträge werden generiert, sobald ich das Projekt geladen habe, selbst wenn nach dem Laden noch nichts aktiv ausgegeben wird.

Das zugehörige Projekt umfasste zu dem Zeitpunkt 114 Connectionsets sowie 18 Bänke. Für das Debugging stelle ich das Projekt über die Cloud zur Verfügung, benannt entsprechend mit der Nummer dieses Tickets.

Über eine lange Laufzeit einer Sitzung haben sich im Log des Kernels zahlreiche Fehlermeldungen im Bereich des ArNetManagers aufgestaut, sodass dieses Log allein über 4,5 Millionen Zeilen enthält. Exemplarische Fehlermeldungen sind unten herausgezogen. In diesem Zusammenhang konnte die GUI keine Verbindung mehr aufbauen, weil der Kernel mit Log schreiben beschäftigt war.

Im Anhang sind die kompletten Logs der Sitzung. Bitte beim Öffnen u. U. Zeit einplanen…

2023-06-17 14:57:46,972 [60] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtDmx(Byte[] packet) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 557
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

2023-06-17 15:25:54,776 [98] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.NullReferenceException: Object reference not set to an instance of an object.
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 602
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

2023-06-17 23:19:20,497 [140] ERROR org.dmxc.lumos.Kernel.DMX.ArtNetFactory - 
System.Net.Sockets.SocketException (10055): Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ReceiveFromAsync(Socket socket, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.ReceiveFromAsync(Memory`1 buffer, SocketFlags socketFlags, EndPoint remoteEndPoint, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP, AsyncCallback callback, Object state)
   at System.Net.Sockets.UdpClient.BeginReceive(AsyncCallback requestCallback, Object state)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 739
  ...
   at System.Threading.Tasks.TaskToApm.TaskAsyncResult..ctor(Task task, Object state, AsyncCallback callback)
   at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint& remoteEP, AsyncCallback callback, Object state)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 705
   at System.Threading.Tasks.TaskToApm.TaskAsyncResult.InvokeCallback()
   at System.Threading.Tasks.AwaitTaskContinuation.<>c.<.cctor>b__17_0(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(ContextCallback callback, Object state, Task& currentTask)
   at System.Threading.Tasks.AwaitTaskContinuation.Run(Task task, Boolean canInlineContinuationTask)
   at System.Threading.Tasks.Task.RunContinuations(Object continuationObject)
   at System.Threading.Tasks.Task.FinishContinuations()
   at System.Threading.Tasks.Task`1.TrySetResult(TResult result)
   at System.Threading.Tasks.ValueTask`1.ValueTaskSourceAsTask.<>c.<.cctor>b__4_0(Object state)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.InvokeContinuation(Action`1 continuation, Object state, Boolean forceAsync, Boolean requiresExecutionContextFlow)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs _)
   at System.Net.Sockets.SocketAsyncEventArgs.<>c.<.cctor>b__179_0(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading.ThreadPoolBoundHandleOverlapped.CompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pNativeOverlapped)
--- End of stack trace from previous location ---
   at System.Threading.Tasks.TaskToApm.End[TResult](IAsyncResult asyncResult)
   at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   at System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 741

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.

Steuert man mit einer Matrix mehrere Geräte oder Sub-Matrizen an, so bleibt die Ausgabe beim Löschen von Werten aus dem Programmer weiter bestehen. Folgendermaßen lässt sich das Problem reproduzieren:

1. Lege 4 Geräte an
2. Lege eine 4×1 Matrix an
3. Patche die Geräte auf die Matrix
4. Wähle die Matrix in der Stage View aus
5. Klicke auf den Lumos Button
6. Stelle eine Farbe für die Matrix ein
7. Gehe nun in den Programmer und lösche den Farbwert für die Matrix

Problem: Die LED-Scheinwerfer behalten nun den letzten Farbzustand, obwohl kein Wert mehr gesetzt ist. Sie gehen erst aus, wenn man den Programmer über “Clear” leert

Erwartetes Verhalten: Die Matrix verhält sich hier wie eine Art Gerätegruppe, wenn also die Werte der Matrix gelöscht werden, muss die Ausgabe der zugeordneten Geräte auch gelöscht werden

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

In den Einstellungen für die Executor-Seiten kann ich festlegen, wie viele Executoren ist pro Seite nutzen möchte. Dieser Wert wird jedoch ignoriert. Egal welchen Wert ich einstelle, es werden grundsätzlich acht Executoren pro Seite angelegt.

Analog zu den zusätzlichen Befehlen zum Herunterfahren des Kernels (siehe Ticket  FS#4394 ) sollten diese aus Konsistenzgründen auch im Umbra hinterlegt werden. Aktuell wären diese zusätzlichen Befehle “quit” und “close”.

Das Kommando “shutdown” ist eigentlich sehr unüblich für Konsolenanwendungen. Gebräuchlicher sind “exit” oder “close”. Diese sollten als weitere Möglichkeiten hinzugefügt werden.

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.

s.o.

Es ist suboptimal, das die FFT-Analyse die CPU auslastet wärend eines File-Imports, dadurch stockt der Resource-Stream extrem, oder der Kernel wird zwischendurch disconnected…..

Mit der Veröffentlichung der Beta 6 kommt nun immer folgende Fehlermeldung im Kernel, wenn ein Projekt Executoren enthält, denen ein Element zugeordnet sind:

21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ScenelistExecutorMemberConfiguration could not be loaded: Number, Name
21:02:46 WARN  ParameterTools - The Following Parameters of Parameterable org.dmxc.lumos.Kernel.Executor.ExecutorMemberConfiguration could not be loaded: Number, Name

Trotz dieser Fehlermeldung stimmt die Zuordnung der Executoren aber und auch die individuelle Konfiguration der Buttons wird richtig geladen.

So war es auch im Zuge des Zusammenfügen der Logs für  FS#5035 . In den dort beigefügten Logfiles ist die genannte Fehlermeldung ebenfalls enthalten, als ich das Projekt aus FS#4772 öffnete. Dieses enthält drei Executoren, denen eine Szenenliste zugeordnet ist.

Auf einer Remote-GUI werden die Vorschau-Icons für die Effekte und Filter nicht anzeigt.

Die Wartezeit, wenn man die Bitmap-Property im “Draw Bitmap”-Node aufruft ist estrem lang (>30s) und das Programm in der Zeit nicht bedienbar. Das ist bei jedem Neuaufruf der Liste so. Besser einmal am Programmstart diese Liste rendern und dann zwischenspeichern.

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.

Da mit dieser Version weitere Master Einzug erhalten, wäre hier eine zentrale Verwaltung für alle Master im Project Explorer hilfreich. Insbesondere für die Speed- und Playback-Master fehlt eine Möglichkeit, diese aus dem Projekt zu löschen.

Daher schlage ich vor, im Projekt Explorer einen weiteren Eintrag mit dem Namen Master sowie mit den festen Unterordnern Group Master, Speed Master, Playback Master hinzuzufügen. In den Unterordnern sind dann folgende Optionen verfügbar / zulässig:

• Group Master: aktivieren und deaktivieren
• Speed Master / Playback Master: neu anlegen, löschen

Da man aktuell Gefahr läuft, sich sein Projekt bei Tippfehlern mit Speed Mastern und Playback Mastern unnötig zu fluten, habe ich diesem Wunsch für den Moment eine mittlere Priorität eingeräumt.

Ich habe in einem leeren Projekt das IA-Fenster geöffnet. Dann lege ich zwei Device Groups an und benenne diese zum Beispiel mit Group 1 und Group 2. Diese finalen Namen kommen nicht im IA-Fenster an, weil sich der Baum nicht aktualisiert.

Gleiches passiert (nicht), wenn ich die Group Master deaktiviere oder wieder aktiviere. Im Baum werden mir zum einen weiterhin beide Master angezeigt und zum anderen noch mit dem Standard-Namen “New Device Group Master”.

Dies ist der im Ticket FS#4500 angekündigte weiterführende Fehlerbericht.

Wird ein Objekt im Projektexplorer im Multi Clientbetrieb verschoben, wird die Verschiebung nicht auf andere Sessions publiziert und nicht abgespeichert.

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

Seit der Beta 5 habe ich mit dem USB Energy Fixer das Problem, dass dieser nicht richtig und deswegen wiederholt ausgeführt wird. Jedes Mal werden die entsprechenden Admin-Rechte jedoch angefordert. Der Rückgabecode wird auch als Fehlermeldung in der GUI ausgegeben.

2022-12-26 13:01:06,849 [14] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - Incorrect USB energy settings - Found incorrect USB energy settings for Nodle interface!
trying to start USBDMXEnergyFixer.exe as Admin on my own to fix registry settings automatically.
Registry-Key: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_16D0&PID_0833'
2022-12-26 13:01:09,860 [Main] WARN  DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager - Timeout when fetching Interface List from DMX Interface Factory DMXControl Projects e.V.
System.TimeoutException: The operation has timed out.
   at DMXLIB.FactoryTimeoutDecorator.get_Interfaces()
   at DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager.LoadInterfaces(IDMXInterfaceFactory factory) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\AbstractDMXInterfaceManager.cs:line 1398
2022-12-26 13:01:16,181 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - Incorrect USB energy settings - Found incorrect USB energy settings for Nodle interface!
trying to start USBDMXEnergyFixer.exe as Admin on my own to fix registry settings automatically.
Registry-Key: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_16D0&PID_0833'
2022-12-26 13:01:19,196 [Log-Thread] WARN  DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager - Timeout Exception when getting Interfaces from Factory DMXControl Projects e.V..
System.TimeoutException: The operation has timed out.
   at DMXLIB.FactoryTimeoutDecorator.get_Interfaces()
   at DMXInterfaceMgmtLIB.AbstractDMXInterfaceManager.IsInterfaceAvailable(String interfaceId) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\DMXInterfaceMgmtLIB\AbstractDMXInterfaceManager.cs:line 194
2022-12-26 13:01:29,502 [14] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:29,506 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:29,514 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 22674 ms in Factory NodleUsbInterfaceFactroy
2022-12-26 13:01:32,703 [56] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:32,707 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:32,709 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 19541 ms in Factory NodleUsbInterfaceFactroy
2022-12-26 13:01:33,626 [64] ERROR org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - EnergyFixer returned Error: -2147450726
2022-12-26 13:01:33,628 [Log-Thread] WARN  org.dmxc.lumos.Kernel.Plugin.KernelDMXInterfaceToUIChannel - DMXControl Projects e.V. - USBDMXEnergyFixer done - unknown ReturnCode from USBDMXEnergyFixer.exe, Code: -2147450726
2022-12-26 13:01:33,633 [Log-Thread] WARN  org.dmxc.lumos.Kernel.DMX.NodleUsbInterfaceFactroy - Execution of Interfaces took 17455 ms in Factory NodleUsbInterfaceFactroy

Wenn ich den Registry-Eintrag über DMXControl 3.2.3 setzen lasse, wird der USB Engergy Fixer in DMXC 3.3 Beta 5 nicht mehr aufgerufen. Zudem trat das Problem mit der Beta 3 nicht.

Lade ich die Cue 1 aus dem exemplarischen Projekt aus  FS#4553  für die Änderung in den Programmer und ändere zum Beispiel den Dimmer nachträglich von 0 auf 100% oder passe die Position von 0; 100 auf 0; 50 an, so kann ich die Cue nicht über den Update-Button aktualisieren. Dies kann ich nur über die Eintrage “Merge” oder “Replace” vornehmen.

Die beigefügten Logfiles zeigen die Tätigkeit bis zur Änderung der Werte. Das Aktualisieren der Cue erfolgte nicht.

Ich möchte in einer Cuelist mit mehreren Cues eine der Cues einige Positionen nach oben oder nach unten verschieben. Dies ist aber mit den Up- / Down-Buttons nur bedingt möglich. Ich kann aktuell eine Cue immer nur eine Position nach oben oder nach unten verschieben. Mehrfaches betätigen der Buttons funktioniert an dieser Stelle nicht.

Der aktuelle Workaround besteht darin, dass ich gewissermaßen “invertiert” verschiebe. Konkret heißt das für den Fall, wo ich die Cue 1 zum Beispiel von Position 1 auf Position 5 verschieben möchte, dass ich die Cues 2 bis 5 markierte und eine Position nach oben verschiebe.

Zur Reproduktion kann ein beliebiges Projekt verwendet werden, das eine Cuelist mit mehreren Cues enthält.

Fehlerbeschreibung

Hinweise

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.

Nachdem Windoof aufgeweckt wurde viele Fehlermeldungen in Umbra und einige im Kernel. Logs im Anhang

s.o.

Nach öffnen von DMXC, laden eines projekts und starten mehrere cuelists via IA werden manche Cuelists (egal wie) auch nach stoppen und via editor neu starten nicht mehr gestartet. zudem fehler in der umbra. logs siehe anhang

Fehlerbeschreibung

Zu der Frage ob das Masterfenster beibehalten werden soll oder nicht, wurde im QRM-Meeting vom 15.05.2021 folgendes verabredet:

1. Das Masterfenster bleibt als separates Fenster erhalten und ist auf dem bekannten Weg erreichbar.
2. Die Master werden auf Basis der neuen Executor-Controls automatisch in dem Masterfenster und alle horizontal nebeneinander anlegt.
3. Das Masterfenster erhält verschiedene Filter, um die Master nur anhand ihres Typs oder / und anhand von bestimmten Werten anzuzeigen.
4. Die Anzeige der Group Master orientiert sich weiterhin an den Einstellungen der jeweiligen Device Groups, ob ein Group Master angezeigt werden soll oder nicht.
5. Die Belegung der Buttons etc. ist nicht konfigurierbar und basiert auf Basis der Standardeinstellungen, mit denen ein Master auch einem Executor zugeordnet wird.
6. Aus den verschiedenen Master-Ordnern kann man das Masterfenster direkt mit einem gesetzten Filter öffnen, um zum Beispiel nur die Group Master oder nur die Parametermaster anzuzeigen.

Beim Duplizieren einer Cuelist, bei der Tracking deaktiviert ist, wird diese Einstellung nicht in die zweite Cuelist übernommen. Der Haken ist zwar nicht gesetzt, aber trotzdem reagiert die Cuelist wie eine mit aktivem Tracking (siehe Diskussion Arne ⇔ JP)

Hallo,
beim herum experimentieren mit der 3.3 Bata in diesem Fall 11, ist mir was aufgefallen.

Ich wollte in einem Connection Set einen Timer verwenden.
Dann habe ich die Eigenschaften des Nodes aufgerufen und dort den Operator Rise Delay ausgewählt.

Aber als dann den Operator ändern wollte, wird mir hierfür nur noch das ausgewählte und keine Liste mehr angezeigt.
Auch die kleinen Bildchen davor die die Funktion verdeutlichen werden nicht mehr angezeigt.

Das passiert in meinem und auch in einem neuen Projekt.

Wie auf den angehängten Bildern zu sehen ist.

Füge ich ein neues Timer Node hinzu kann ich auch bei diesem die Funktion nur einmal ändern,
kann dann aber bei dem vorherigen Node die Funktion wieder ändern usw.

Gruß Steff

Fehlerbeschreibung

Hinweise

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

 bei Lumos.GUI.Windows.ProjectExplorerView.<>c.<ShowProperties>b__254_0(IProjectExplorerNode c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\ProjectExplorer\ProjectExplorerView.cs:Zeile 2817.
 bei System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
 bei Lumos.GUI.Windows.ProjectExplorerView.ShowProperties(ICollection`1 nodes) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\ProjectExplorer\ProjectExplorerView.cs:Zeile 2817.
 bei Lumos.GUI.Windows.TimecodePlayer.v3.ExecutorTrackViewModel.<OpenContentProperties>d__27.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\TimecodePlayer\v3\ViewModel\Track\Executor\ExecutorTrackViewModel.cs:Zeile 332.

 bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
 bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
 bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Es fehlt die Möglichkeit mit dem Marker wieder an den Anfang der Timecode Show zu springen

Um das Fenster des Timecode-Players zu öffnen muss bei jedem Neustart von DMXC das Fenster über den Project-Explorer einmal öffnen und wieder schließen, erst dann kann man es über Steuerungsfenster → Timecodeplayer öffnen. Bevor man den TImecodeplayer einmal über den Explorer geöffnet hat ist dieser Eintrag nicht vorhanden. Ich verstehe nicht welchen nutzen das haben soll und würde mir wünschen das Fenster direkt öffnen zu können.

Fehlerbeschreibung

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.

Nach jedem Start von DMXC braucht der TImecode-Player ca. 10-20 Sekunden um sich zu öffnen. In dieser Zeit reagiert die gesamte GUI von DMXC nicht mehr. Bin mir an der Stelle nicht sicher ob das ein Bug ist oder einfach nicht anders geht. Sollte letzteres der Fall sein würde ich einen kurzen Ladebalken etc. vorschlagen, da ich als User so jedes Mal den Eindruck habe, DMXC sei abgestürzt.

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.

Nach dem Anlegen eines neuen Projekts erscheint die Abfrage, ob das neu angelegte Projekt auch direkt geladen werden soll. Allerdings fehlt in diesem Fenster der entsprechende Text, wie im beigefügten Screenshot zu sehen. Das Problem besteht sowohl in der englischen als auch in der deutschen GUI.

Eine Show im TCP lässt sich zwar ohne Audio recorden aber nicht wieder abspielen. Projekt mit mehren TCP-Shows ohne Audios als Beispiel im Anhang.

Veränderte Einstellungen der Darstellung der FFT Grafik (Threshold, Ratio, Bandwith) werden nicht abgespeichert und es wird auch kein Dirty-Flag gesetzt.

Ich habe folgendes Test-Setup:

- Drei Cuelisten die jeweils einem Executor zugeordnet sind
- Ein angeschlossenses Midi-Pult, wo für jeden Executor Button 1 und der Fader im IA via Dynamic Executor Page verdrahtet sind
- Eine Show im TCP die nur aus einer Audio (60 bpm click track) und der Aufnahme von erwähntem Button 1 der Executoren besteht

Nachdem ich nun die Show im TCP häufig gestartet, pausiert, gestoppt (sowohl einmaliges Stoppen (→ roter Marker springt auf letzte Startposition) als auch zweites Stoppen (→ roter Marker springt auf null) ) und Executoren aufgenommen habe, habe ich folgende Fehler, welche erst nach und nach aufgetreten sind, aber am Anfang noch kein Problem waren:
- zweites Stoppen (→ roter Marker springt auf Null) funktioniert nicht mehr, nur noch das erste Stoppen (→ roter Marker springt auf letzte Start-Position) funktioniert
- roten Marker durch doppelklicken in der Timeline an einen bestimmten Punkt setzen funktioniert nicht mehr, auch das hat anfangs noch funktioniert

Logs und Projekt im Anhang