Bugtracker DMXControl 3

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.

Nach dem Abschluss des Ladevorgangs eines beliebigen Projekts nach dem initialen Start einer Sitzung erscheint im Umbra die folgende Fehlermeldung:

20:51:25 ERROR BidirectionalStreamBridgeWithResponseFilter - Response Sender SendDmxChanges has faulted.
System.OperationCanceledException: The operation was canceled.
   at System.Threading.Channels.AsyncOperation`1.GetResult(Int16 token)
   at System.Threading.Channels.ChannelReader`1.ReadAllAsync(CancellationToken cancellationToken)+MoveNext()
   at System.Threading.Channels.ChannelReader`1.ReadAllAsync(CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 113
--- End of stack trace from previous location ---
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 113

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.

Ich habe das Projekt aus FS#4772 geladen und ein bisschen in der Stage View herumgeklickt, um unterschiedliche Geräte bzw. die Gerätegruppe auszuwählen. Schließe ich das Projekt dann (ich habe keine Änderungen vorgenommen), erscheint mit einer gewissen Regelmäßigkeit die folgende Fehlermeldung im Kernel.

20:41:35 ERROR BidirectionalStreamBridgeWithResponseFilter - Response Sender SendDevicePropertyChanges has faulted.
System.OperationCanceledException: The operation was canceled.
   at System.Threading.Channels.AsyncOperation`1.GetResult(Int16 token)
   at System.Threading.Channels.ChannelReader`1.ReadAllAsync(CancellationToken cancellationToken)+MoveNext()
   at System.Threading.Channels.ChannelReader`1.ReadAllAsync(CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 113
--- End of stack trace from previous location ---
   at Umbra.Bridge.BidirectionalStreamBridgeWithResponseFilter`2.<>c__DisplayClass7_0.<<ClientSideTaskWithFilter>b__1>d.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Umbra\src\Bridge\BidirectionalStreamBridgeWithResponseFilter.cs:line 113

In den beigefügten Logfiles habe ich dies einmal gezielt hervorrufen können.

Im Kernel wird in einer der ersten Zeilen des Logs die genaue Versionsnummer vermerkt:

2022-01-06 16:40:37,100 [Main] INFO  org.dmxc.lumos.Kernel.Run.KernelRunManager - DMXControl V3.3.0.887 Alpha8 starting! (x86)

Ein solcher äquivalenter Eintrag fehlt im Log des Umbras. Hier kann man nur über

2022-01-06 16:51:20,132 [Main] INFO  Umbra.Run.UmbraRunManager - Umbra Build Time: 06.01.2022 13:32:25 UTC

darauf schließen, welcher Build der aktuellen Programmversion zu Grunde liegt.

In der Titelleiste des Umbras erscheint zwar die Version richtig, nämlich DMXControl V3.3.0.887, der weitere Zusatz ist aber bei “Alpha 7” stehen geblieben.

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

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 in meinem ersten Test eine Cuelist im Cuelist-Track, die nur ca. 20% des gewählten Musikstücks “verlichtet”. Ist dieser Punkt erreicht, stoppt die Audio-Wiedergabe hart. Um dies aber insgesamt schöner zu gestalten, sollte die Wiedergabe der Timecode-Show erst unter folgenden Bedingungen automatisch beendet werden:

• Wenn das Ende des längsten Tracks erreicht ist. Dabei ist es egal, ob es sich beispielsweise um den Audio-Track oder einen Cuelist-Track handelt.
• Wenn der letzte Audio-Track bei der Lautstärke ausgeblendet wurde und kein anderer Track länger ist.

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.

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.

Im Kontextmenü innerhalb eines Cuelist-Tracks besteht die Möglichkeit, eine (weitere) Cuelist diesem Cuelist-Track hinzuzufügen. Allerdings führt dieser Eintrag ins leere. Ein entsprechender Auswahldialog, welche Cuelist aus dem Projekt eingefügt werden soll, fehlt noch.

Schließe ich ein Projekt mit einer Timecode-Show und lade das Projekt anschließend neu, kann mir die Grafik der Audiodatei nicht mehr angezeigt werden. Der Kernel gibt folgenden Log-Eintrag dazu aus.

Open: Failed to open '[...]\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff'. The process cannot access the file '[...]\Software\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff' because it is being used by another process.
...
23:43:58 ERROR AudioManager - Unable to process FFT / Wave for Zack Merci - ray of light [feat. Nieko - NCS Release].mp3 after several tries....

Bereits beim Schließen des Projekts wirft der Kernel eine Fehlermeldung. Die Dateien liegen zu diesem Zeitpunkt weiter im Temp-Verzeichnis des Kernels.

21:54:48 ERROR ProjectManager -
System.IO.IOException: The process cannot access the file '[...]\DMXControl 3.3.0\Kernel\Temp\Zack Merci - ray of light [feat. Nieko - NCS Release].mp3.0.tiff' because it is being used by another process.
   at System.IO.FileSystem.DeleteFile(String fullPath)
   at System.IO.File.Delete(String path)
   at org.dmxc.lumos.Kernel.Audio.AudioManager.RemoveFFT(AudioMetadata m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 318
   at org.dmxc.lumos.Kernel.Audio.AudioManager.removeAudio(String name) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 301
   at org.dmxc.lumos.Kernel.Audio.AudioManager.<org.dmxc.lumos.Kernel.Run.ILumosProjectManager.closeProject>b__62_0(String c) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 1163
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at org.dmxc.lumos.Kernel.Audio.AudioManager.org.dmxc.lumos.Kernel.Run.ILumosProjectManager.closeProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Audio\AudioManager.cs:line 1163
   at org.dmxc.lumos.Kernel.Project.ProjectManager.<>c__DisplayClass48_0.<closeProjectNoLock>b__1(ILumosManager m) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 278
   at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
   at org.dmxc.lumos.Kernel.Project.ProjectManager.closeProjectNoLock(IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 274

Aktuell muss ich DMXC einmal komplett neu starten.

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

Ich habe einem Cuelist-Track mehrfach die gleiche Cuelist zugeordnet. Die sollen mehrfach hintereinander ausgeführt werden. Allerdings geschieht dies aktuell nur ein einziges Mal, nämlich an der Stelle, wo die Cuelist das erste Mal im Cuelist-Track positioniert ist. Die weiteren Male erfolgt keine Wiedergabe.

Füge ich beispielsweise eine Cuelist einem Cuelist Track zu, erscheint in der GUI eine Fehlermeldung, die im Log der GUI folgenden Eintrag generiert:

2023-06-25 21:43:11,923 [Log-Thread] DEBUG Lumos.GUI.Net.gClient.Timecode_gClient - AddChildrenToTrackAsync
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Net.gClient.Timecode_gClient.<AddChildrenToTrackAsync>d__32.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Net\gClient\Timecode_gClient.cs:Zeile 275.

Möchte ich bei aktiviertem Dark Theme in einer Tabellenzelle einen Wert ändern, so ist dieser auf Grund der falschen Schriftfarbe beim Editieren nicht zu lesen. Aktuell kann ich wie in der beispielhaft beigefügten Fotomontage im Patching Dialog zu sehen nur durch Auswählen des gesamten Zelleninhalts die Werte erkennen.

Ich lade exemplarisch das beigefügte Projekt. Wenn ich dann die GUI “hart” neustarte, das heißt die Anwendung über den Taskmanager schließe und die GUI neu starte, werden die Icons der Devic Groups in der Stage View nicht an ihrem ursprünglichen Platz anzeigt. Stattdessen befinden sich beide Icons der Device Groups übereinander gestapelt im Null-Punkt oben links in der Stage View. Die Icons der Geräte selbst befinden sich dagegen an ihrem ursprünglichen Platz.

Im Anhang finden sich die Logs der Sitzung sowohl vor als auch nach dem Neustart der GUI. Kernel und Umbra liefen die ganze Zeit durch.

Füge ich einem Projekt Geräte hinzu, während in der Stage View die Option “Show Device / Group Number” oder “DMX-Adress” aktiviert und diese sichtbar ist, wird die folgende Fehlermeldung im Log der GUI ausgegeben.

2021-05-10 19:12:45,308 [Main GUI] ERROR org.dmxc.lumos.XNAViews.StageView.StageView - Der Wert darf nicht NULL sein.
Parametername: text
System.ArgumentNullException: Der Wert darf nicht NULL sein.
Parametername: text
   bei Microsoft.Xna.Framework.Graphics.SpriteFont.MeasureString(String text)
   bei org.dmxc.lumos.XNAViews.StageView.StageView.DrawIconStrings(RectangleF bounds, Single bottom, Single right, Single& bottomOut, Single& rightOut) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1391.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.Draw(Rectangle clipingRectangle) in D:\Jenkins\workspace\Lumos_Pipeline_master\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1139.

Das Hinzufügen der Geräte selbst erfolgt dabei wie erwartet, weswegen ich keine (weiteren) Logfiles beifüge.

Wie im beigefügten Screenshot zu sehen, werden die Icons der 3D-Mäuse angezeigt. Diese haben dort aus meiner Sicht nichts zu suchen.

Es macht keinen Unterschied, ob das 3Dconnexion-Plugin aktiviert ist oder nicht.

Beim Arbeiten mit den Zoom-Steuerelementen musste ich feststellen, dass

• beim Klicken auf das + bzw. - in der Lupe gar keine Aktion ausgelöst wird (siehe Bild 1 und 2)
• an der im Bild 3 gezeigten Mausposition der Ausschnitt immer noch vergrößert wird, obwohl sich die Maus bereits im Bereich zum Verkleinern der Ansicht befindet.

Grundsätzlich wäre die Erwartungshaltung, dass ich mit der Maus innerhalb eines gedachten Rechtecks um das jeweilige Icon herum die jeweilige Funktion nutzen und somit auch direkt auf die Icons klicken kann (siehe Bild 4).

Aktuell kann man aus der Stage View heraus bereits Geräte zu einer neuen (leeren) Device Group hinzufügen.

Hier könnte ich mir einen zusätzlichen Workflow als hilfreich vorstellen, mit dem man in der Stage View ein oder mehrere Geräte auch einer existierenden Device Group hinzufügen kann. Bis dato ist dies ja nur im Add Device möglich, aber nur für eine Gruppe.

Ich habe das Ticket mal auf Usuability Relevant gesetzt, um damit herauszufinden, ob dieser Mehrwert auch von jemand anderes gesehen wird.

Füge ich eine Auswahl von mehreren Geräten nachträglich manuell über den Project Explorer einer Stage View hinzu, werden diese trotz vorhandenem Platz sehr weitläufig positioniert, wie im beigefügten Screenshot ist.

Der Fehler tritt auf, wenn ich ein beliebiges Icon (also Device, Device Group oder Matrix) in seiner Größe vergrößere. Reduziere ich die Größe des Icons wieder auf die Standardgröße von 32 x 32 Pixel, erfolgt die Positionierung der Icons wie gewohnt.

Dies ist ein Punkt, der von meiner Seite aus auch erst mit DMXControl 3.2.1 behoben werden kann.

Füge ich aus dem beigefügten Projekt die Devices CMW (10), CMW (20), CMW (30) zusätzlich zu den bereits in der Stage View vorhandenen Devices hinzu, beginnt diese sich nicht wie gewohnt zu verhalten:

• Obwohl ich alle Geräte auswähle, werden von den CMW (10), CMW (20) und CMW (30) beim Verschieben nur jeweils eines der Devices mitverschoben.
• Sind mehr als zwei der Devices CMW (10), CMW (20), CMW (30) in der Stage View platziert, wird die Anordnung nicht mehr gespeichert.

In den Logfiles sind mir hierzu folgende Einträge aufgefallen.

<2019-10-10 21:58:53,767 [Main GUI] ERROR Lumos.GUI.Windows.LiveView.LiveStageView - Das Objekt des Typs "org.dmxc.lumos.XNAViews.StageView.DeviceMatrix" kann nicht in Typ "org.dmxc.lumos.XNAViews.StageView.DeviceOrBeamIcon" umgewandelt werden.
System.InvalidCastException: Das Objekt des Typs "org.dmxc.lumos.XNAViews.StageView.DeviceMatrix" kann nicht in Typ "org.dmxc.lumos.XNAViews.StageView.DeviceOrBeamIcon" umgewandelt werden.
   bei org.dmxc.lumos.XNAViews.StageView.BeamIcon.get_Location() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\DeviceOrBeamIcon.cs:Zeile 278.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.GetBounds() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 421.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.GetBounds() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 437.
   bei Lumos.GUI.Windows.LiveView.IconFacade.CalculateBounds() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\IconFacade.cs:Zeile 40.
   bei Lumos.GUI.Windows.LiveView.LiveStageView.addDevice(LiveViewDeviceMetadata deviceM) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\LiveStageView.cs:Zeile 1213.

2019-10-10 21:58:57,905 [Main GUI] ERROR org.dmxc.lumos.XNAViews.StageView.StageView -

2019-10-10 22:03:15,157 [Log-Thread] WARN  LumosLIB.Tools.LumosTools - Unable to save project in LiveViewManager
System.InvalidCastException: Das Objekt des Typs "org.dmxc.lumos.XNAViews.StageView.DeviceMatrix" kann nicht in Typ "org.dmxc.lumos.XNAViews.StageView.DeviceOrBeamIcon" umgewandelt werden.
   bei org.dmxc.lumos.XNAViews.StageView.BeamIcon.get_Location() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\DeviceOrBeamIcon.cs:Zeile 278.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.GetBounds() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 421.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.GetBounds() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 437.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.set_Location(PointF value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 384.
   bei Lumos.GUI.Windows.LiveView.IconFacade.set_Location(Point value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\IconFacade.cs:Zeile 29.
   bei Lumos.GUI.Windows.LiveView.LiveStageView.onDeviceParameterChanged(Object sender, String parameterName, Object newValue) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\LiveStageView.cs:Zeile 2055.
   bei Lumos.GUI.Facade.AbstractGUIFacade.OnFacadeParameterChanged(String name, Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\AbstractGUIFacade.cs:Zeile 132.
   bei Lumos.GUI.Facade.AbstractGUIFacade.setFacadeParameter(FacadeParameter parameter, Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\AbstractGUIFacade.cs:Zeile 95.
   bei Lumos.GUI.Facade.AbstractGUIFacade.setFacadeParameter(String name, Object value) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Facade\AbstractGUIFacade.cs:Zeile 77.
   bei Lumos.GUI.Windows.LiveView.LiveStageView.WritePositionsFacadeParameters() in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\LiveStageView.cs:Zeile 842.
   bei Lumos.GUI.Windows.LiveView.LiveViewManager.Lumos.GUI.Run.IGuiProjectManager.saveProject(LumosGUIIOContext context) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\LiveView\LiveViewManager.cs:Zeile 596.
   bei Lumos.GUI.Run.GuiRunManager.<>c__DisplayClass34_0.<saveProject>b__0(IGuiManager m) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Run\GuiRunManager.cs:Zeile 341.

Bei den Devices habe ich einen zweiten Beam definiert, um die 2. Tilt-Achse über die Funktion Position ansprechen zu können. Das Projekt und die vollständigen Logs sind beigefügt.

Im Zuge von Tests rund um das Ticket  FS#3851  fiel mir der folgende Fehler auf: Besitzt ein Matrix- oder Radix-Gerät neben der Definition der Matrix bzw. Radix auch noch eine RGB+-Definition, um die gesamte Lampe auf eine bestimmte Farbe zu setzen, wird dieses von der Stage View ignoriert.

Der Colorpicker spricht die DMX-Kanäle für rot, grün, blau und weiß ordnungsgemäß an, die Stage View zeigt diese eingestellte Farbe jedoch nicht an. Erst wenn ich eine Farbe über das Matrix- bzw. Radix-Window einstelle, zeigt die Stage View diese Farbe an.

Im Anhang sind zwei vereinfachte DDFs zu finden, die das Problem reproduzieren. Aufhänger war hier der Futurelight Eye-7 RGBW Zoom.

Mit dem Ticket  FS#3573  ist dieser Fehler nicht vergleichbar, da der dort angezogene Showtec Expression 8000 Q4 über eine solche RGB+-Defintion nicht verfügt.

Füge ich ein Radix-Gerät meinem Projekt hinzu und möchte über den Colorpicker die Gesamtfarbe festlegen, gibt die Stage View die eingestellte Farbe nicht wieder. Die DMX-Ausgabe arbeitet aber wie gewünscht. Es wäre gut, wenn Radix-Geräte am Ende genauso arbeiten, wie klassische Matrix-Geräte - hier funktioniert das Festlegen und Visualisieren einer festen Farbe vom Colorpicker in der Stage View

Das verwendete DDF des Radix-Geräts ist im Anhang beigefügt.

In der gleichen Session wie in Ticket  FS#3567  ist mir folgender Eintrag im GUI-Log aufgefallen. Ich könnte mir denken, dass dieser Eintrag im Zusammenhang mit den Blades steht.

2019-04-26 14:15:45,941 [1] ERROR TreeGridMode - Die Methode oder der Vorgang ist nicht implementiert.
System.NotImplementedException: Die Methode oder der Vorgang ist nicht implementiert.
   bei Lumos.GUI.Windows.Programmer.ProgrammerModelValue.<>c.<GetCellValueWrapper>b__24_23(Object v) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\LumosGUI\src\Windows\Programmer\ProgrammerModel.cs:Zeile 767.
   bei org.dmxc.lumos.XNAViews.ListView.Mode.DataGrid.CellValueWrapper.Update(Boolean force) in D:\Jenkins\workspace\Lumos_3.2_Release\Lumos\XNAViews\src\XNAViews\ListView\Mode\DataGrid\Member\Cell\CellWrapper\CellValueWrapper.cs:Zeile 93.
2019-04-26 14:15:46,168 [1] ERROR TreeGridMode - Die Methode oder der Vorgang ist nicht implementiert.

Füge ich in ein DDF ein Blade-Modul ein, werden diese in der Stage View grundsätzlich als geschlossen visualisiert. Das bedeutet, bei einem Klick auf Lumos öffnet sich zwar der Shutter, der Lichtkegel bleibt aber weiterhin schwarz. Der Dimmer arbeitet im Hintergrund regulär, was ich anhand der DMX-Ausgabe und durch das Einblenden der Intensity sehen kann. Kommentiere ich das Blade-Modus aus, funktioniert das DDF wie gewohnt.

Deaktiviere ich ein Gerät, so treten in der Stage View Darstellungsfehler auf wie im beigefügten Screenshot zu sehen ist.

Getestet mit Build 1503

Aktuell wird jede (Wert-) Änderung in der Stage View protokolliert, also nicht nur Dimmer, sondern auch Farben oder Goborotationen. Lasse ich also über den Abend die Stage View die ganze Zeit mit laufen, wächst das Logfile der GUI auf eine unter Umständen für den PC nicht mehr händelbare Größe an. Daher sollte das Logging für den Normalbetrieb unbedingt deaktiviert werden. Ggf. könnte man drüber nachdenken, das Logging bei Bedarf einzuschalten, wenn man sich auch die Debug-Infos ausgeben lässt.

Getestet mit Build 1500

Und plötzlich fing die StageView wild an zu Flackern trotz zoomen, verschieben und Reset. Ich weiß, es ist keine hilfreiche Fehlerbeschreibung - schaut einfach mal in die angehängten Logs der GUI. Da gibt es viele nette Einträge.

Getestet mit Build 1492

Es ist in der laufenden Sitzung zweimal passiert, dass die Stage View nicht vollständig gezeichnet wurde. Die Ursache ließ sich gerade noch nicht richtig eingrenzen. In den Logs der GUI tauchen folgende Einträge auf:

System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "Texture2D".
   bei Microsoft.Xna.Framework.Helpers.CheckDisposed(Object obj, IntPtr pComPtr)
   bei Microsoft.Xna.Framework.Graphics.EffectParameter.SetValue(Texture value)
   bei org.dmxc.lumos.XNAViews.StageView.DeviceOrBeamIcon.OnGetIconEffect(Effect effect) in D:\Jenkins\workspace\Lumos_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\DeviceOrBeamIcon.cs:Zeile 201.
   bei org.dmxc.lumos.XNAViews.StageView.AbstractIconBase.GetIconEffect(Effect effect, Single time, AliasIcon alias) in D:\Jenkins\workspace\Lumos_Release\Lumos\XNAViews\src\XNAViews\StageView\Icons\AbstractIconBase.cs:Zeile 515.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.drawIcon(RectangleF bounds, Single time, AbstractIconBase abstractIconBase, AliasIcon alias) in D:\Jenkins\workspace\Lumos_Release\Lumos\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1584.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.DrawIcons(RectangleF bounds) in D:\Jenkins\workspace\Lumos_Release\Lumos\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1533.
   bei org.dmxc.lumos.XNAViews.StageView.StageView.Draw(Rectangle clipingRectangle) in D:\Jenkins\workspace\Lumos_Release\Lumos\XNAViews\src\XNAViews\StageView\StageView.cs:Zeile 1247.

Das Problem ist hier, dass die Fehlermeldung so häufig in das Logfile geschrieben wird, dass dieses binnen wenigen Sekunden merklich größer wird. Sobald die Stage View im Hintergrund ist und zum Beispiel durch den Project Explorer “überlagert” wird, stoppt das Fortschreiben der Meldungen (siehe auch zweites Video in WhatApp-Gruppe vom 26.01. um 12:17 Uhr).