Bugtracker DMXControl 3

Fehlerbeschreibung

Haben Sie einen Fehler entdeckt? Dann nutzen Sie bitte folgendes Template und beachten die Hinweise für eine reibungsfreie Bearbeitung der Tickets.

Fehlerbeschreibung

Erwartetes Verhalten

Bislang können die Inputs des Input Selectors nur mit ganzen Zahlen sowie Buchstaben bezeichnet werden.

Hier sollte es auch möglich sein, Kommawerte in den Bezeichnungen der Inputs anzugeben, also zum Beispiel 12.5 oder 36.1.

Beim LAden eines alten Projekts bekomme ich folgenden Fehler:

FATAL MainProcessRunable - Main Runnable seams stuck in an endless loop! You might have to restart DMXC… Please report this!

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

Erwartetes Verhalten

Beim Laden des fehlerhaften angehängten DDFs werden sämtliche mit dem Kernel verbundenen GUIs ohne weitere Warnung/Meldung geschlossen (also nicht nur getrennt, sondern tatsächlich komplett geschlossen)
Bis einschließlich Version 3.2.3 wurde eine Fehlermeldung angezeigt und die fehlerhafte Zeile im DDF rot markiert, was hier nicht passiert.

Im Kernel wird folgende Meldung ausgegegen:

13:11:07 ERROR Resource_gClient - ExistsResourceCore
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at Grpc.Net.Client.Internal.HttpClientCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)
   at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, CallOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 202
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 197
   at org.dmxc.lumos.Kernel.Net.gService.Resource_gClient.ExistsResourceCore(EResourceDataType type, String name, Boolean sync) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\gService\Resource_gClient.cs:line 188
13:11:07 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_2_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:10 ERROR Resource_gClient - ExistsResourceCore
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at Grpc.Net.Client.Internal.HttpClientCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)
   at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, CallOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 202
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 197
   at org.dmxc.lumos.Kernel.Net.gService.Resource_gClient.ExistsResourceCore(EResourceDataType type, String name, Boolean sync) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\gService\Resource_gClient.cs:line 188
13:11:10 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_3_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:13 ERROR Resource_gClient - ExistsResourceCore
Grpc.Core.RpcException: Status(StatusCode="Cancelled", Detail="Call canceled by the client.", DebugException="System.OperationCanceledException: The operation was canceled.")
 ---> System.OperationCanceledException: The operation was canceled.
   --- End of inner exception stack trace ---
   at Grpc.Net.Client.Internal.HttpClientCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)
   at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation)
   at Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, CallOptions options) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 202
   at UmbraCommon.ResourceClient.ResourceClientClient.ExistsResource(ResourceExistsRequest request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosProtobuf\obj\Release\netstandard2.0\Common\ResourceServiceGrpc.cs:line 197
   at org.dmxc.lumos.Kernel.Net.gService.Resource_gClient.ExistsResourceCore(EResourceDataType type, String name, Boolean sync) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Net\gService\Resource_gClient.cs:line 188
13:11:13 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_4_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:13 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_5_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:13 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_6_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:13 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_7_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!
13:11:13 ERROR GobowheelHandlerNode - The Icon |:::_ICON_ID_8_:::| defined in the "val" Attribute in Node gobowheel doesn't exist!

Hallo,
wenn ich im Projekt Explorer eine neues Projekt anlege werde ich dann gefragt ob ich das importierte Projekt Laden möchte.

Es müsste aber doch neues Projekt heißen !

Dies ist in der deutschen, französischen und engloischen Sprachversion so.

Was ich im in dem Zusammenhang noch gesehen habe, ist das die Buttons in dem Fenster , im deutschen ja und Nein, das auch im englischen und Französischen dort Ja und Nein steht.

Gruß Steff

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

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.

Habe viele verschiedene Geräte gelöscht, soweit problemlos. Anschließend habe ich versucht Gerätegruppen zu löschen. Hierbei ist allerdings nicht passiert, egal welche Gruppe, es war nicht möglich sie zu löschen. Nun wollte ich DMXC schließen und dabei noch einmal speichern, dabei habe ich folgende Fehlermeldung im Kernel bekommen

- - - - - - - - - - -

21:15:20 ERROR ProjectManager - Error at save Project
System.NullReferenceException: Object reference not set to an instance of an object.

 at org.dmxc.lumos.Kernel.Scene.Entry.AbstractSceneEntry.saveToManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Entry\AbstractSceneEntry.cs:line 1014
 at org.dmxc.lumos.Kernel.Scene.Entry.DevicePresetReferenceEntry.saveToManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\Entry\DevicePresetReferenceEntry.cs:line 297
 at org.dmxc.lumos.Kernel.Scene.AbstractEntryContainer.saveToManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\AbstractEntryContainer.cs:line 523
 at org.dmxc.lumos.Kernel.Scene.AbstractScene.saveToManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Scene\AbstractScene.cs:line 361
 at org.dmxc.lumos.Kernel.SceneList.SceneList.org.dmxc.lumos.Kernel.Resource.ILumosSaveable.saveToManagedTree(ManagedTreeItem item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\SceneList\SceneList.cs:line 2194
 at org.dmxc.lumos.Kernel.Project.SceneListManager.org.dmxc.lumos.Kernel.Project.IProjectResourceUser<org.dmxc.lumos.Kernel.SceneList.ISceneList>.SaveItem(ISceneList item, LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\SceneListManager.cs:line 559
 at org.dmxc.lumos.Kernel.Project.ProjectContainer`1.Save(LumosIOContext context)+MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectContainer.cs:line 245
 at org.dmxc.lumos.Kernel.Project.LoadedProjectVersion.saveProject(LumosIOContext context) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\LoadedProjectVersion.cs:line 355
 at org.dmxc.lumos.Kernel.Project.ProjectManager.SaveProjectToStream(Stream projectStream, IEnumerable`1 clientReferences, IProgress`1 progress, Boolean resetDirty, Boolean isAutosave) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Project\ProjectManager.cs:line 587

- - - - - - - - -

Logs und Projekt (zuletzt speicherbare Version) im Anhang.

Edit: Mir ist aufgefallen, dass das angehängte Projekt “0.0.421” schon beschädigt und nicht mehr ladbar ist. Deshalb habe ich es noch um das vollständige Projekt auch mit vorangegangenen Versionen desen angehängt.

Ich habe eine 4mb große Audiodatei, siehe Anhang, auf einen neuen Track in einer neuen Show (”1”) im TCP gezogen. Hierbei erschien die angehängte Fehlermeldung in der GUI und das belgen des Tracks ist somig nicht möglich.

Projekt („Jubiläum Tanzatelier 24“) und Logs ebenfalls im Anhang

Edit: Problem tritt auch in einem komplett neuen Projekt mit einer komplett anderen Audio auf. Projekt zum nachstellen („Audio Track Test“) ist angehängt.

Lösche ich in angehängtem Projekt beliebige Geräte (im Fall der in den Logs zu sehen ist handelte es sich um die Geräte “The Fab”, “1”, “2”, … “111”) crasht die GUI und schließt sich. Starte ich nun die GUI und verbinde diese wieder, speicher das Projekt und lade es neu, ist es beschädigt und lässt sich nicht mehr laden.
Logs und Projekt im Anhang.

Nun habe ich versucht ohne DMXC neu zu starten ein neuess Projekt anzulegen um den oben beschrieben Fehler in einem Lehren Projekt zu testen. Nach dem erstellen des Projekts und laden dieses ist mir erneut die GUI gecrasht. Logs als “B” im Anhang.

Nun habe ich um weitere folge Fehler zu vermeiden DMXC einmal komplett neu gestartet.

Im zuletzt erstellten Projekt habe ich nun zwei Gerät hinzugefügt, eine Cuelist mit Werten für diese erstellt und diese Cuelist auf einen Executor zugewiesen. Anschließend habe ich das Projekt gespeichert (Projekt zu diesem Stand als “C.1”im Anhang). Nun habe ich die entsprechenden Geräte gelöscht. Hierbei ist mir erneut die GUI gecrasht, Logs zu diesem Zeitpukt als “Logs C.1” im Anhang. NUn habe ich das Porjekt gespeichert und DMXC komplett neu gestartet. Anschließend habe ich das Projekt (Projekt zu diesem Stand als “C.2” im Anhang) versucht zu laden. Das hat problemlos fumktioniert. Nun habe ich noch die Gerätegruppe zu den Geräten gelöscht. Auch hierbei ist mir die GUI wieder gecrasht. Logs als “Logs C.2” im Anhang.

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.

Fehlerbeschreibung

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)

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

Fehlerbeschreibung

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.

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.

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

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.

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

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.

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.

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.

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.

Fehlerhaftes Verhalten in einem großen Projekt (als “Audio Import 02” im Anhang) der Beta 10:
- Audio importiert (Größe wird nur als „n.a.“ dargestellt)
- TCP Show mit Audio-Track erstellt
- Versucht Audio auf track im TCP gezogen, gescheitert, da nicht das Drag&Drop-Symbol, sondern ein “Nicht-erlaubt-Zeichen” erscheint → Audio kann im TCP nicht verwendet werden
- Projekt gespeichert und DMXC neu gestartet
- File ist nicht mehr im Files Pool
- In der Vermutung, dass zu viele Audios im Projekt sind alle Audios aus dem TCP entfernt und anschließend gelöscht (keine Out of Memory- oder Error-Meldung(en) in den Logs zu finden)
- DMXC neu gestartet
- Erneut versucht die Audios sowie Audios, welche in der Beta 9 schonmal importiert wurden, zu importieren
- Problem bleibt

Erwartetes Verhalten in einem neuen Projekt (Projekt als “Audio Import 01” im Anhang) der Beta 10 oder großen Projekten der Beta 9 oder früher (abgesehen davon, dass die Größe einer Datei erst ab dem Neustart angezeigt wird, wie gesagt erwartetes Verhalten):
- Neues Projekt erstellt
- Audio importiert (Größe wird nur als „n.a“. dargestellt)
- TCP Show mit Audio-Track erstellt
- Audio auf track im TCP gezogen
- Show im TCP geöffnet, funktioniert
- Projekt gespeichert und DMXC neu gestartet
- Größe wird im Files Pool korrekt dargestellt
- TCP Show wird problemlos geladen

Beide Projekte sowie die Logs im Anhang. Audio aus Urheberrechtsgründen nicht angehängt und aus dem Projekt Audio Import 01 gelöscht, es handelt sich bei diesen um zwei bis drei Minuten MP3´s.

Fehler wirkt für mich zusammenhängend mit  FS#4932 , obwohl der Fehler zwischenzeitlich (bspw. in der Beta 9) nicht aufgetreten war.

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

Über die Projekt Administration exportiertes Projekt wird zwar gespeichert, der Fortschrittsbalken der UI bleibt jedoch auch nach mehren Minuten bei 0%, siehe Anhang. Wird die Projekt Administration geschlossen und neu geöffnet ist der Balken nicht mehr zu sehen. Fehler nur bei dem selben Projekt reproduzierbar.

Logs, Projekt (hart über den Project-Store Ordner herauskopiert= und Screenshot im Anhang.

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

Fehlerbeschreibung

Erwartetes Verhalten

Hinweise

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.

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

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.

Werden Executor Pages via IA gewechselt (Screenshot des Connection-Sets im Anhang) führt dies dazu, dass das Highliten in der GUI (normalerweise ist die ausgewählte Executor Page in einem helleren Grau als alle anderen Pages) nicht mehr funktioniert. Video zu diesem Verhalten ebenfalls im Anhang.

Ich habe folgende Testumgebung (identisch wie in  FS#5138  und  FS#5139  ):

- 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

Nun ändere ich aber einen Faktor: Ich nehme nun nicht nur noch den erwähnten Button 1 im TCP sondern sowohl Button 1 als auch den Fader von drei Executoren via Midi über Dyxnamic Executoren auf.
Damit man sich ein Tempo der Änderungen vorstellen kann: mein Track hat wie gesagt 60 BPM und ich habe auf jeden vierten Takte Änderungen gemacht (also 15 mal pro Minute).
Dies verkraftet DMXC aber absolut nicht mehr. Zu erst hatte ich kurzzeitige Aktualisierungsprobleme in der GUI (heißt der TCP freezte für geschätzt ca. fünf Sekunden). Nachdem ich dies ca. eine Minute lang gemacht hatte, schmierte mir die GUI aber komplett ab und ich habe in der GUI Fehlermeldungen bekommen (siehe Screenshot im Anhang). GUI war nicht mehr responsible und ich musste DMXC komplett schließen und neu starten.

Logs (wie gesagt, habe geschlossen und neu gestartet, es handelt sich also um den vorletzten Start in den Logs) und Projekt sind im Anhang

Ich habe folgende Testumgebung (identisch wie in  FS#5138 ):

- 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

In dieser Umgebung tritt folgender Fehler auf:
Wird ein Executor via Midi geflasht (Fehler tritt bei mir nur auf, wenn er über Midi geflasht wird, nicht wenn er über die GUI bedient wird) und gleichzeitg in einer SHow im TCP verwendet, löst sich der Flash nicht mehr, sobald man ihn nicht mehr flasht. Der Flash Button löst sich dann nur noch lösen, indem man die TCP Show beendet, auch wenn er in der TCP Show eigentlich nicht mehr aktiv war.

Projekt und Logs sind im Anhang.

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

Das normale “Presets”-Fenster listet die Presets ja alphabetisch (außer aktuell bei Updates, glaube ich).
Im Projektexplorer sind sie nach Funktion und Erstellugsreihenfolge (?) sortiert.
Wenn man aber eine Spezialszene Preset hinzufügen will, scheinen die Einträge im Dropdown quasi zufällig sortiert, neue Presets sind jedenfalls nicht am Ende und auch nicht alphabetisch einsortiert.
Ich würde mir eine alphabetische Sortierung wir im Presetfenster wünschen.

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.

Ändere ich den Seitennamen oder die Seitennummer einer Executor-Seite in den Eigenschaften der Seite, wird die Änderung zwar übernommen, das Dirty-Flag aber nicht gesetzt.

Versuche ich mit Beta 8 oder Beta 9 das angehängte Projekt zu öffnen, stürzt die GUI ab (Dialog für ungefangene Exception).

Im GUI-Log findet sich mehrfach folgende Exception:

2023-08-27 12:59:45,710 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
System.InvalidOperationException: Ein ItemsControl ist nicht konsistent mit seiner Elementquelle.
 Weitere Informationen finden Sie in der inneren Ausnahme. ---> System.Exception: Informationen für Entwickler (Text-Schnellansicht zum Lesen verwenden):
Die Ausnahme wurde ausgelöst, da der Generator für Steuerelement 'System.Windows.Controls.ListBox Items.Count:28' mit dem Namen 'LPresetList' eine Reihe von CollectionChanged-Ereignissen empfangen hat, die nicht mit dem aktuellen Status der Elementsammlung übereinstimmen.  Die folgenden Unterschiede wurden festgestellt:
  Gesammelte Anzahl 27 unterscheidet sich von der tatsächlichen Anzahl 28.  [Gesammelte Anzahl ist (Anzahl bei letztem Reset + #Adds - #Removes seit letztem Reset).]

Eine oder mehrere der folgenden Quellen haben möglicherweise falsche Ereignisse ausgelöst:
     System.Windows.Controls.ItemContainerGenerator
      System.Windows.Controls.ItemCollection
       System.Windows.Data.ListCollectionView
  *     LumosControlsWPF.Tools.DispatchedObservableCollection`1[[LumosControlsWPF.Controls.UserControls.Presets.ViewModel.Interface.IPresetItemViewModel, LumosControlsWPF, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]
(Die beteiligten Quellen werden als die wahrscheinlichere Ursache des Problems betrachtet.)

Die häufigsten Ursachen umfassen (a) das Ändern der Sammlung oder deren Anzahl ohne Auslösen eines entsprechenden Ereignisses sowie (b) das Auslösen eines Ereignisses mit falschem Index- oder Elementparameter.

Die Stapelüberwachung der Ausnahme beschreibt wie die Inkonsistenzen festgestellt wurden, jedoch nicht wie diese aufgetreten sind.  Um eine zeitnahe Ausnahme zu erhalten, legen Sie die zugehörige Eigenschaft 'PresentationTraceSources.TraceLevel' für den Generator auf den Wert 'High' fest und führen das Szenario erneut aus.  Eine Möglichkeit dazu ist die Ausführung eines Befehls ähnlich dem folgenden:
   System.Diagnostics.PresentationTraceSources.SetTraceLevel(myItemsControl.ItemContainerGenerator, System.Diagnostics.PresentationTraceLevel.High)
im Direktfenster.  Dadurch wird die Erkennungslogik nach jedem CollectionChanged-Ereignis ausgeführt, sodass die Anwendung verlangsamt wird.

   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.Windows.Controls.ItemContainerGenerator.Verify()
   bei System.Windows.Controls.VirtualizingStackPanel.MeasureChild(IItemContainerGenerator& generator, IContainItemStorage& itemStorageProvider, IContainItemStorage& parentItemStorageProvider, Object& parentItem, Boolean& hasUniformOrAverageContainerSizeBeenSet, Double& computedUniformOrAverageContainerSize, Double& computedUniformOrAverageContainerPixelSize, Boolean& computedAreContainersUniformlySized, Boolean& hasAnyContainerSpanChanged, IList& items, Object& item, IList& children, Int32& childIndex, Boolean& visualOrderChanged, Boolean& isHorizontal, Size& childConstraint, Rect& viewport, VirtualizationCacheLength& cacheSize, VirtualizationCacheLengthUnit& cacheUnit, Int64& scrollGeneration, Boolean& foundFirstItemInViewport, Double& firstItemInViewportOffset, Size& stackPixelSize, Size& stackPixelSizeInViewport, Size& stackPixelSizeInCacheBeforeViewport, Size& stackPixelSizeInCacheAfterViewport, Size& stackLogicalSize, Size& stackLogicalSizeInViewport, Size& stackLogicalSizeInCacheBeforeViewport, Size& stackLogicalSizeInCacheAfterViewport, Boolean& mustDisableVirtualization, Boolean isBeforeFirstItem, Boolean isAfterFirstItem, Boolean isAfterLastItem, Boolean skipActualMeasure, Boolean skipGeneration, Boolean isAncestorLookingForFirstItem, Boolean& hasBringIntoViewContainerBeenMeasured, Boolean& hasVirtualizingChildren)
   bei System.Windows.Controls.VirtualizingStackPanel.MeasureOverrideImpl(Size constraint, Nullable`1& lastPageSafeOffset, List`1& previouslyMeasuredOffsets, Nullable`1& lastPagePixelSize, Boolean remeasure)
   bei System.Windows.Controls.VirtualizingStackPanel.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
   bei System.Windows.Controls.ItemsPresenter.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
   bei System.Windows.Controls.ScrollContentPresenter.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.DockPanel.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV)
   bei System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged)
   bei System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV)
   bei System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.ScrollViewer.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Border.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Control.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Grid.MeasureCell(Int32 cell, Boolean forceInfinityV)
   bei System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV, Boolean& hasDesiredSizeUChanged)
   bei System.Windows.Controls.Grid.MeasureCellsGroup(Int32 cellsHead, Size referenceSize, Boolean ignoreDesiredSizeU, Boolean forceInfinityV)
   bei System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
   bei System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Border.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Control.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Grid.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei MS.Internal.Helper.MeasureElementWithSingleChild(UIElement element, Size constraint)
   bei System.Windows.Controls.ContentPresenter.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Border.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.Control.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Controls.DockPanel.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.Documents.AdornerDecorator.MeasureOverride(Size constraint)
   bei System.Windows.FrameworkElement.MeasureCore(Size availableSize)
   bei System.Windows.UIElement.Measure(Size availableSize)
   bei System.Windows.ContextLayoutManager.UpdateLayout()
   bei System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
   bei System.Windows.Media.MediaContext.InvokeOnRenderCallback.DoWork()
   bei System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
   bei System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
   bei System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
   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)

Wird eine Show im TCP gestoptt, springt zwar der Marker wieder an den Anfang, es wird aber nicht automatisch an den Anfang gescrollt. Man muss also immer händisch zurück-scrollen. Dies hat micht verwundert, da in einer laufenden Show im TCP automatisch mit dem Marker mitgescrollt wird.

Wunsch: TCP scrollt nach stoppen automatisch an die Position des Markers.

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.