Bugtracker DMXControl 3

Durch das Einbauen von Gruppen in Gruppen kann es zu Ladeproblemen kommen, weil Gruppe B in Gruppe A eingefügt werden soll, diese beim Laden aber noch nicht existiert.

Fehlerbeschreibung

Hinweise

Fehlerbeschreibung

s. Überschrift. Wäre nice :)

Das Aktivieren und Deaktivieren von Bänken über den Menüpunkt “Bank > Aktive” ist aktuell nicht möglich. Der Befehl wird nicht durchgereicht, sodass sich auch der farbige Balken nicht ändert.

Gruppe → Color-Chaser auf die Farbe → Speedmaster auf die Duration

arbeitet wie erwartet

Speedmaster auf 0 → Schweinwerfer springen auf die Farbe die ohne Effekt anliegt

Die 1D Effekte reagieren wie erwartet: aktuelle Farbe des Effektes wird gehalten

ich probier gerade noch mit der Alpha 6
Hier ist ja beim Color Chaser der Blend Mode hinzugekommen.
Da der Blend Mode in der 3.2.2 noch nicht vorhanden war, wird der Multiply Mode eingestellt.
Damit funktionieren die Cuelists aber nicht. Das sehr ist ungünstig.

Welcher Mode würde dem Blendverhalten aus der 3.2.2 entsprechen ?
Dieser Mode sollte beim Importieren eines Projektes aus der 3.2.2 Version als Default Mode dann eingestellt und verwendet werden.
Damit die Cuelisten nach dem Import. bzw übertragen in der 3.3.0 Version auch so funktionieren ohne groß was an dem Projekt einstellen zu müssen.

Ich hab da mal ein Testprojekt angehängt.
Mit Endung .Zip zum Test in der 3.2.2
Mit Endung .dmz zum Test in der 3.3.0 Alpha 6
Bilder hiervon sind auch angehängt

Das beigefügte Projekt enthält drei Softdesks mit zahlreichen Steuerelementen. Beim ersten Laden klappt in der Regel alles noch einwandfrei, wenn die letzte Fensteranordnung aufgerufen wird, die alle drei Softdesks anzeigt. Wenn ich aber die nachfolgend genannten Schritte ausführe, findet die GUI zwei der drei Softdesks nicht, obwohl diese zuvor noch geöffnet werden konnten. Die zugehörigen Fenster bleiben leer.

1. Projekt über “Close Project” schließen.
2. Ein neues, leeres Projekt erstellen lassen.
3. Beigefügtes Projekt erneut öffnen und letzte Fensteranordnung aufrufen.

Ursprung dieses Tickets war, dass bei meinen Projekten aus DMXC 3.2.2 die noch deutlich umfangreicheren Softdesks bereits beim ersten Laden des Projekts nach dem Start der Sitzung nicht aufgerufen werden konnten, was zur Folge hat, dass das gesamte Projekt nicht mehr funktioniert. Hinterlege ich im Projekt die Softdesks einzeln in einem separaten Projekt ohne weitere Inhalte, indem ich die über die Datei “SoftdeskMaster.xml” auskommentiere, konnten alle Softdesks für sich einzeln geladen werden. Sobald aber alle “aktiv” sind, klappt dies nicht. Spannenderweise wechselst dies auch durch, wenn ich die Reihenfolge der Einträge in der Datei “SoftdeskMaster.xml” ändere.

Im Anhang findet sich das vereinfachte Testprojekt mit den speziell für dieses Ticket angelegten Softdesk sowie die Log-Dateien für einen kompletten Durchlauf, wie er oben beschrieben ist.

Alle Effekte und Filter funktionieren nach dem Prinzip, dass sie einen gewissen eigenen Wert auf den Basiswert der Geräteeigenschaft aufaddieren. Alle Effekte und Filter? Nein, einen gibt es, der anders arbeitet: Der Random Value Filter. Der Min-Wert des Random Value Effekts überschreibt hart den Basiswert. Das ist inkonsistent zu den anderen Effekten und Filtern. Der Min-Wert wird aber auch nicht benötigt, weil man ja den Basiswert hat. Daher sollte der Min-Wert Eintrag in dem Effekt entfernt werden und dafür zur Abwärtskompatibilität den Min-Wert in den Basiswert kopieren. Man müsste überlegen, ob letzteres ok ist oder ob man entsprechend einen Eintrag in die ToDos machen sollte.

Zur Überprüfung des im Ticket  FS#4415  wollte ich dieses nach dem Import entsprechend in DMXControl 3.3 Alpha 7 laden. Dies ist aber auf Grund der folgenden Meldung im Kernel nicht möglich:

2021-12-02 19:14:23,620 [12] ERROR org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter - Error in Reading KeyValue Pair: Attribute

   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 146.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateManagedTree(XmlElement node, Double version, EIOFlags flags, List`1 errors) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 127.

In den beigefügten Logs ist die vollständige Fehlermeldung enthalten. Das entsprechende Projekt liegt ebenfalls bei.

Grob zusammenfasst beinhaltet das Projekt folgendes:

• 20 Geräte, zugeordnet zu 4 verschiedenen Gerätegruppen
• 1 Cuelist
• 2 Makroboard-Profile, wobei nur das erste eine entsprechend einfache Zuweisung im Input Assignment besitzt

in der aktuellen 3.3 Alpha kann man im PE unter Presets keine Ordner anlegen oder umbenennen. Wenn ein Preset aus “AddCue” (s.Bild) erstellt wird, wird unter Presets ein Ordner mit dem Namen (Empty, nicht änderbar) erstellt, in dem der Preset liegt.

ich bin da immer mal wieder am Testen mit der 3.3 Alpha 7.
Da ist mir gestern aufgefallen das das Highlight Node nicht ganz funktioniert.
Ich habe mein “großes” Projekt Importiert und geladen. ist mit der 3.2.2 erszellt worden.
Im Projekt habe ich eine Signal Lamp am Ausgang vom Highlight Node.
Betätige ich nun meinen Button über ein T-Flip Flop am Eingang des Highlight Node.
Highlight funktioniert aber am Ausgang wird immer noch False ausgegeben.
Also funktioniert meine Signal Lamp nicht.
Tausche ich dann im Input Assigment das Node aus, funktioniert es wieder.

Gleiche Konstellation habe ich auch bei Freeze und Blackout gebaut, hiermit funktioniert alles.
Ich habe das zum Test in einem kleinem Projekt zusammen gebastelt,
Auch hier tritt das auf. Ist im Anhang.

Projekt läd nach speichern in den Kernel nicht mehr.
Arne weiß Bescheid

In Vorbereitung auf den heutigen Stream habe ich mir den Temp-Fader nochmal angeschaut, nachdem die Info kam, die Funktion sei nun vollständig implementiert. Im Zuge dieses Tests sind gleich zwei Dinge aufgefallen, die sich am besten mit dem beigefügten Projekt reproduzieren lassen.

1. Die Steuerung der Intensity der Cuelists ist kaputt gegangen. Die Executoren 1.1 und 1.3 übergeben die Werte zwar an die Cuelists. Eine Umsetzung findet aber nicht mehr statt.
2. Temp-Fader wird nur aktualisiert, wenn die Cuelist auf Executor 1.3 eingefadet, zwischen den Cues übergefadet oder ausgeblendet wird. Ist die Cue zu 100% eingeblendet, wirkt sich der Temp-Fader nur noch als zusätzlicher Intensity-Regler für Helligkeit, aber nicht für den Grad der Einmischung der Werte.

Zum zweiten Punkt wäre folgende Erwartungshaltung. Ist die Cuelist auf Executor 1.1 aktiv, soll der Temp-Fader zu jedem Zeitpunkt bestimmen

• den Wert, wie weit die Farbe eingemischt wird zwischen 0% und 100% grün / blau alternierend.
• den Winkel, wie “hoch” die Geräte schwenken zwischen 0° und 95° (dies ist besser live zu sehen).

Hinzu kommt, dass beim Überblenden der Cuelist auf Executor 1.3 nicht von Cue 1 nach Cue 2 übergeblendet wird. Stattdessen Blitzen die im Hintergrund gesetzten Werte (Defaultwerte oder die Cuelist auf Executor 1.1) auf und faden mit der gesetzten Fadezeit der Cue 1 bzw. Cue 2 aus. Für dieses Verhalten ist der Wert des Temp-Faders irrelevant.

nicht vorhanden

Hallo
als ich die 3.3 Alpha 8 installiert habe und mein Projekt geöffnet habe, sind die Elemente im Input Assignment alle übereinander angeordnet.
Auch wird die eingestellte Position und der Zoom nicht übernommen.
Stelle ich hier was ein und schließe das Connectionset und öffne es wieder sieht es wieder wie vorher aus.

Durch einen dummen Zufall ist mir aufgefallen, dass DDFs, welche sowohl im Verzeichnis “Icons” und / oder “Images” liegen, ebenfalls einem Projekt hinzufügt werden können. In diesem Fall übernimmt DMXControl 3 beim Speichern sogar diese zusätzlichen Pfade, wie in dem beigefügten Projekt zu sehen ist.

Um den Fehler gezielt zu reproduzieren, habe ich bewusst den DMX-Mode bei den Devices 2 und 3 angepasst, damit ich die Software entsprechend zum erneuten Laden der verfügbaren DDFs bewegen konnte.

Aus meiner Sicht sollte dies unterbunden werden. DDFs haben ausschließlich direkt im Verzeichnis “UserDevices” zu liegen, nicht in den Unterordnern “Icons” oder “Images”. Eigene Ordner werden im Übrigen bereits ignoriert.

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

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

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

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

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

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

Ändere ich bei einem bereits einmal gespeicherten und wieder geöffneten Projekt zum Beispiel bei einer Auswahl von Devices in der Stage View die Einstellung “Enabled”, so friet die GUI ein. Um weiterarbeiten zu können, muss ich den Prozess “hart” über den Task Manager beenden.

Dieses Ticket beschreibt den eigentlich beobachteten Fehler aus Ticket FS#4683. Im Nachhinein betrachtet war es dort die gleiche Vorgehensweise, nur eben mit dem Eintrag “Mirror horizontal”. Hier war das Projekt zum Zeitpunkt des Auftreten des Fehlers zuvor ebenfalls innerhalb der Sitzung nochmal neu geladen worden.

Im Anhang befindet sich das Projekt sowie die Logfiles, wobei die der GUI nur bis zu dem Zeitpunkt erfasst sind, bis diese über den Taskamanager beendet wurde.

Ich nutze den Sparkle-Effekt, um damit die Farbe einer Gerätegruppe zu steuern. Trage ich unter Peak beim Sparkle-Effekt zum Beispiel einen ColorMaster ein, erscheint bei Bestätigung der Eingabe der folgende Fehler und der Effekt bleibt stehen.

20:33:53 WARN  SceneFadeTicker - Exception triggering Item: start or end value have wrong type!
System.ArgumentException: start or end value have wrong type!
   bei org.dmxc.lumos.Kernel.PropertyValue.Fade.AbstractFader`1.fade(Object startValue, Object endValue, Double percent) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Fade\AbstractFader.cs:Zeile 53.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.SparkleFilter.doFilter(IPropertyValue input, Int64 timeInMs, Int64 delta) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\SparkleFilter.cs:Zeile 180.
   bei org.dmxc.lumos.Kernel.PropertyValue.Filter.AbstractEffectFilter.doFilter(IPropertyValue input) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\Filter\AbstractEffectFilter.cs:Zeile 58.
   bei org.dmxc.lumos.Kernel.PropertyValue.AbstractPropertyValue.getPropertyValue(Int64 timeInMsAbs) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 402.
   bei 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_master_2\Lumos\src\Kernel\PropertyValue\AbstractPropertyValue.cs:Zeile 338.
   bei 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_master_2\Lumos\src\Kernel\Scene\Fade\FadeDecorator.cs:Zeile 96.
   bei 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_master_2\Lumos\src\Kernel\Scene\Delay\DelayDecorator.cs:Zeile 38.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AutoFadeDecorator.triggerFade() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AutoFadeDecorator.cs:Zeile 33.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractValueFadeDecorator.triggerFade(Boolean& deregister) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractValueFadeDecorator.cs:Zeile 201.
   bei org.dmxc.lumos.Kernel.Scene.Fade.AbstractFadeDecorator.trigger() in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\Fade\AbstractFadeDecorator.cs:Zeile 65.
   bei org.dmxc.lumos.Kernel.Scene.SceneFadeTicker.processBag(ProcessableTickerBag bag, Int64 now) in D:\Jenkins\workspace\Lumos_Pipeline_master_2\Lumos\src\Kernel\Scene\SceneFadeTicker.cs:Zeile 218.

Gleiches gilt auch für andere Master.

Mache ich das Gleiche zum Beispiel mit dem Chaser-Effekt, kann ich den ColorMaster nutzen, um die Farbe zu steuern. Entsprechend Patricks Aussage müssen hier Code-Segmente explizit kopiert werden.

Ich habe ein Softdesk mit mehreren Controls angelegt. Von diesen habe wiederum einige gelöscht und den Softdesk Designer geschlossen. Speichere und schließe ich das Projekt und lade ein neues, bleibt das gelöschte Softdesk Control noch im Input Assignment erhalten, wie im beigefügten Screenshot zu sehen.

Da ich das Problem nicht direkt im gleichen Kontext wie Ticket  FS#4577  sehe, habe ich dieses neue Ticket erstellt.

Im Anhang findet sich das Projekt sowie die Logs der Sitzung.

Versuche ich das Projekt aus #FS4399 zu öffnen wird es augenscheinlich geladen, sobald ich die Frage “Load last Layout” mit Ja beantworte friert die GUI ein und der PC wird insgesamt quälend langsam. Die GUI muss über den Taskmanager beendet werden.

Beim Programieren muss ich im moment oft viele Songs ins Project importieren, dabei kommt oft unten stehende Exception.
Einfach 20 songs auf einmal importieren und der fehler tritt auf

2022-01-24 21:34:36,429 [Log-Thread] DEBUG org.dmxc.lumos.Kernel.Net.gService.Resource_gService - Exception when closing the Backend Stream
Grpc.Core.RpcException: Status(StatusCode=”OK”, Detail=”“)

 bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 bei System.Runtime.CompilerServices.TaskAwaiter.GetResult()
 bei org.dmxc.lumos.Kernel.Net.gService.Resource_gService.<_saveResource_RequestReceived>d__17.MoveNext() in D:\Git-Repos\Lumos\master\LumosLIB\src\Kernel\Net\gService\Resource_gService.cs:Zeile 394.

Kann ein Projekt nicht erfolgreich abgespeichert werden, wird das Dirty Flag trotzdem auf “Projekt unverändert” zurückgesetzt. Aus meiner Sicht sollte das nicht so sein und erst den Status “Projekt gespeichert” annehmen, wenn im Kernel der Logeintrag

00:00:40 INFO  Messages - Message from ...: Saved Project to GUI Undefined, Path MyProject.dmz

erscheint. Ein typisches Beispiel ist, um das Problem schnell zu reproduzieren, das Projekt mittels 7zip oder ähnlich “anzusehen”, wodurch DMXC keine Schreibrechte mehr auf die Datei hat. Siehe hierzu auch mein Ticket  FS#4651 .

Ist das Projekt zum Ablauf des eingestellten Timers nicht “Diry”, das heißt, das Dirty Flag ist nicht gesetzt, wird das automatische Speichern zu diesem Zeitpunkt ausgesetzt. Der Timer wird aber neu gestartet.

Entscheidung aus QRM 22.1

Ich denke, es ist sinnvoll den FileImport abzukürzen, wie bei den FFT-Tiffs, es macht vor allem sinn bei Vielen, oder großen Dateien.
Dies würd weniger Resourcen auf nicht so leistungsstarken rechner binden.
Ich schreibe das Ticket gerade wärend 33 mp3s importiert werden und der laptop ist grad nicht so responsiv xD

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

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

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

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

Werden gewisse Elemente wie zum Beispiel Nodes im Input Assignment durch Alternativen ersetzt, erhält das betreffende Node einen Hiidden-Flag. Dieses Flag sorgt dafür, dass diese Nodes für neue Projekte nicht mehr zur Verfügung stehen. Bestehende Projekte können aber noch geladen werden.

Der Nutzer wird im Form eines ToDos darauf hingewiesen, dass diese Element in der zukünftigen Version entfernt wird.

Wenn ich eine neue Gobo Affinity sowohl in einem neuen, leeren Projekt als auch in einem Projekt mit bereits gepatchten Geräten erstelle und hierzu das zu Grunde liegende Gobo auswählen möchte, so wird in dem Auswahlfenster kein Inhalt angezeigt - egal ob der Halen “Included in project” gesetzt ist oder nicht oder ob ich etwas in das Suchfeld eintrage.

Das zusammenstellen der Gobos für eine Goboliste funktioniert dagegen. Dort werden die verfügbaren Gobos angezeigt.

Im Anhang habe ich die Logfiles beigefügt, die den Punkt für ein leeres Projekt protokollieren.

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

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

Hi,

das hinzufügen von Farben zu einer Colorlist funktioniert nicht richtig. Man kann eine Farbe im Fenster “Edit Item List” hinzufügen. Nach bestätigen mit OK ist die neue Farbe jedoch nicht in der Colorlist.

Gruß
Frank

Ich habe mehr oder minder unbeabsichtigt ein Msuikstück mit einer Länge von 76 Minuten einem leeren Projekt hinzugefügt. Im Kernel erscheinen daraufhin die folgenden Einträge:

21:07:37 ERROR LumosTools - Can't get Tags of Resource [[SOUNDFILE]]
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.
   bei System.IO.MemoryStream.set_Capacity(Int32 value)
   bei System.IO.MemoryStream.EnsureCapacity(Int32 value)
   bei System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   bei LumosLIB.Tools.CommonTools.<CopyStreamCore>d__95.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1396.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosLIB.Tools.CommonTools.CopyStream(Stream source, Stream destination, Int32 blockSize, IProgress`1 progressCallback, Boolean disposeSource) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1372.
   bei LumosLIB.Tools.CommonTools.<ToMSCore>d__81.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1218.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bei LumosLIB.Tools.CommonTools.ToMS(Stream stream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosToolsLIB\src\Tools\CommonTools.cs:Zeile 1205.
   bei LumosLIB.Tools.LumosTools.SimpleFileAbstraction..ctor(Stream stream, String name, Boolean disposeStream) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 573.
   bei LumosLIB.Tools.LumosTools.<GetDetails>d__42.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Tools\LumosTools.cs:Zeile 615.
21:10:45 ERROR AudioManager - Unable to process FFT / Wave for [[SOUNDFILE]] after several tries....

Auf Grund dieses Fehlers bleiben die Background-Tasks unerledigt beim Status “Waiting” stehen, weil hier die FFT nicht generiert werden konnte. In solchen Fällen sollte der entsprechende Tasks mit einem Fehler abgebrochen werden, als weiterhin den Status “Waiting” beizubehalten.

Fehlerbeschreibung

Lösche ich eine Cuelist aus einem Projekt, welches ich zuvor unmittelbar gespeichert habe, wird mir dies im Dirty Flag nicht angezeigt.

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

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

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

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

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

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

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

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

Ist ein Connectionset fehlerhaft, werden die im Projekt enthaltenen Softdesks nicht geladen. Damit sind alle Connectionsets nicht nutzbar, die Elemente eines Softdesks enthalten - und nicht nur die, in denen ein Fehler aufgetreten ist. Im Log der GUI taucht dann folgender Eintrag auf:

2022-05-07 13:48:16,099 [Main GUI] ERROR Lumos.GUI.WindowManager - Error when instantiating Object from persistString: Lumos.GUI.Windows.Softdesk.SoftdeskWindow#8af8329a-c9ce-46da-8a74-ce20b5f9301a
System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> org.dmxc.lumos.Kernel.Exceptions.NotExistingException: Can't find a SoftdeskModel with ID 8af8329a-c9ce-46da-8a74-ce20b5f9301a
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.getSoftdeskModelFromID(String id) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 67.
   bei Lumos.GUI.Windows.Softdesk.SoftdeskWindow.GetInstanceFromPersistString(String softdeskId) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Softdesk\SoftdeskWindow.cs:Zeile 41.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   bei System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   bei System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   bei System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   bei Lumos.GUI.WindowManager.GetContentFromPersistString(String persistString) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\WindowManagement\WindowManager.cs:Zeile 1856.

Als Beispiel kann das Projekt aus  FS#4850  herangezogen werden. Auch wenn dieses nur ein Connectionset enthält und dieses einen Fehler auswirft, ist dennoch zu sehen, dass alle Elemente des Softdesks pauschal nicht geladen werden.

Zur Prüfung des Installers nach den umfangreichen Änderungen habe ich mir auch mal ein paar Projekte angesehen. Dabei ist mir das Problem unter die Finger gekommen, dass im Build 142 die Graphen des Input Assignments nicht gespeichert werden können. Welches Projekt man dabei nimmt, ist vollkommen egal.

Der Fehler lässt sich reproduzieren, wenn man zum Beispiel ein Cuelist- oder ein Macroboard-Node in ein Connectionset schmeißt und dieses Projekt dann speichern will. Dann spuckt der Kernel folgende Fehlermeldung aus:

17:14:53 WARN  ResourceManager - Unable to save Resource Graphs.xml of Type Project
System.InvalidOperationException: 'org.dmxc.lumos.Kernel.Input.v2.NameNumberIDValue' kann nicht serialisiert werden, weil dafür kein parameterloser Konstruktor verfügbar ist.
   bei System.Xml.Serialization.TypeDesc.CheckSupported()
   bei System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference, Boolean throwOnError)
   bei System.Xml.Serialization.ModelScope.GetTypeModel(Type type, Boolean directReference)
   bei System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping(Type type, XmlRootAttribute root, String defaultNamespace)
   bei System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(String name, Object value, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 390.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 311.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item, XmlDocument dest) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 317.
   bei org.dmxc.lumos.Kernel.Resource.Xml2ManagedTreeConverter.GenerateData(ManagedTreeItem item) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\Xml2ManagedTreeConverter.cs:Zeile 294.
   bei org.dmxc.lumos.Kernel.Resource.Datastore.FileBackendDatastore.SaveResource(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\Datastore\FileBackendDatastore.cs:Zeile 480.
   bei org.dmxc.lumos.Kernel.Resource.ResourceManager.SaveResourceInternalAsync(EResourceType type, LumosResource data, IProgress`1 progress) in D:\Jenkins\workspace\Lumos_Pipeline_3.3\Lumos\src\Kernel\Resource\ResourceManager.cs:Zeile 219.
   bei org.dmxc.lumos.Kernel.Resource.AbstractResourceManager.<SaveResourceAsync>d__86.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosLIB\src\Kernel\Resource\AbstractResourceManager.cs:Zeile 732.

Ein neues Testprojekt kann ich auf Grund der Art des Fehlers nicht beifügen. Daher verweise ich auf mein zuletzt für das Ticket  FS#4856  erstelle Projekt.

Da dieses Problem sich aus meiner Sicht unmittelbar als Testblocker herauskristallisieren würde, habe ich mich entschlossen, ausnahmsweise ein Ticket für eine Zwischenversion zu schreiben.

Die Midi-Implementierung ist buggy und sollte zumindest auf einen Stand gebracht werden, dass sie an sich funktioniert. Dieses Ticket sammelt verschiedene Dinge, die mir aufgefallen sind und die ich fixe (als Dokumentation zum Testen).

1. Das Midi-Feedback ist doppelt, sprich einmal über den Midi-Teil selbst und einmal über das IA. So lässt sich die Rückmeldung über das IA aktuell effektiv nicht durchführen weil der rückgemeldete Wert aus dem IA teilweise über die Midi-Teil-Interne Rückmeldung überschrieben wird. Das führt dazu, dass der Status eine laufenden Cuelist nicht korrekt mit einem hellen Button symbolisiert werden kann
2. Der Midi-Teil aktualisiert aktuell bei einer Midi-Message am Input (egal ob von einem Button, Fader oder Encoder) alle definierten Buttons statt nur das entsprechende Control. Das führt in Verbindung mit nachfolgendem Problem zu “Geisterauslösung”
3. Aktuell sind Input- und Feedback-Wert zu einem Wert zusammengefasst (zumindest bei Buttons, bei anderen Controls TBC). Das entspricht nicht ganz der Erwartung, weil so unter gewissen Umständen (bei einem Update des Buttons am Input, siehe z.B. vorherigen Punkt) zu einer falschen Auslösung kommen kann. Daher sollte es getrennte Pfade für Input und Output geben

Deaktiviere ich von einer oder von mehreren Device Groups den / die zugehörigen Group Master, so wird diese Information prorgrammintern nicht weiter durchgereicht, wenn

• ich die zugehörigen Device Groups in der laufenden Sitzung neu erstellt und
• ich das Projekt noch nicht gespeichert habe.

Dem entsprechend werden eigentlich deaktivierte Group Master noch unter dem gleichnamigen Unterordner der Master im Project Explorer und damit auch im Master-Fenster angezeigt. Erst

• nach dem Speichern des Projekts (ein Neuladen ist an dieser Stelle nicht erforderlich) oder
• beim erneuten Aktivieren und Deaktivieren

arbeiten alle Bereiche wie erwartet zusammen. Die Änderung der Namen wird aber bereits sofort immer weiterverarbeitet.

Ändere ich die Werte für Fade Factor und Speed Factor entweder extern über das Cuelist-Node im Input Assignment oder auch direkt im Cuelist Editor, werden diese Werte beim Starten der Cuelist immer auf den Standardwert von 100% zurückgesetzt. Der gewählte Wert für die Intensität wird aber beibehalten.

Ist die Cuelist dann aktiv, kann ich die Werte für Fade Factor und Speed Factor ändern, wo sie dann auch das erwartete Verhalten zeigen.

Im Anhang findet sich ein kleines Projekt mit einer Cuelist, wo ich die Fadezeiten länger gewählt habe, um auch während des Fades Zeit zu haben, die Werte für Fade Factor und Speed Factor zu ändern.

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

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

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

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

Fehlerbeschreibung

Erwartetes Verhalten

Fehlerbeschreibung

20:50:37 ERROR BidirectionalStreamBridgeWithResponseFilter - Request Listener SendCuelistProgressChanges has faulted.
System.IO.IOException: The client reset the request stream.
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestPipeReader.AdvanceTo(SequencePosition consumed, SequencePosition examined)
   at Grpc.AspNetCore.Server.Internal.PipeExtensions.ReadStreamMessageAsync[T](PipeReader input, HttpContextServerCallContext serverCallContext, Func`2 deserializer, CancellationToken cancellationToken)
   at Grpc.AspNetCore.Server.Internal.HttpContextStreamReader`1.<MoveNext>g__MoveNextAsync|11_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 56
--- 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 56

Cuelist wurde hinzugefügt, im IA wird sowohl bei EIngänge als auhc bei Ausgänge anstatt des Namens der Cuelist “neue Szenenliste” angezeigt

Ich habe in der Gruppenhandhabung im Device Control Werte geändert, diese werden allerings nicht angezigt. Es muss zuerst etwas anderes angezeigt werden (z.B. von Gruppenhandhabung auf Eigenschaften wechseln und wieder zurück) bevor Änderungen geladen werden.

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.

GrandMaster spricht nur Werte aus Cuelists aber nicht aus dem Programmer an.

Beispiel und Logs sind im Anhang.

Im Ticket FS#4790 hatte ich beiläufig berichtet, dass sich Kernel und GUI nicht mit dem Umbra verbinden, wenn der PC mit zwei Netzwerken verbunden ist. Was mir aber auch mehr oder minder regelmäßig passiert, wenn ich die Netzwerkkonfiguration ändere. Damit meine ich, dass

• der Laptop erst noch per WLAN und per Kabel mit einem Netzwerk verbunden war, ich aber dann die WLAN-Verbindung getrennt bzw. sogar den WLAN-Adapter abgeschaltet habe.
• ich aus bestimmten Gründen die Netzwerkkonfiguration ändere, sowohl Wechsel der statischen IP oder auch Wechsel von statischer IP-Adresse hin zu DHCP oder umgekehrt.

Auf meinem Laptop kann ich es mit der Beta 3 wie folgt reproduzieren:

• Variante 1: Meine Laptops sind per WLAN verbunden (Adresszuweisung per DCHP). Ich stelle eine kabelgebundene Verbindung zum gleichen Netzwerk her (Sowohl feste IP-Adresse über Zuteilung vom Router als auch DCHP) und deaktiviere die WLAN-Verbindung über den Infobereich in der Taskleiste. Diese Variante kann ich sowohl unter Windows 10 als auch Windows 11 nachvollziehen. (Zugehörige Logs unter Windows 10 siehe DMXControl3Logs_20221120_184500.zip)
• Variante 2: Bei meinem Laptop war das WLAN noch über Windows aktiv. Ich habe mein Handy per USB-Kabel angeschlossen, um darüber einen mobilen Hotspot zu erhalten. Dabei wird ein neues “kabelgebundenes” Netzwerk erstellt. Ich hatte dann erst das WLAN abgeschaltet und DMXC3.3 in der Beta 5 gestartet. Nach dem Start stellten GUI und Kernel keine Verbindung zum Umbra her. Auch ein Neustart von DMXC3 mit über Windows eingeschalten WLAN reichte nicht.

In dem genannten Fall muss ich meinen Laptop immer neu starten, wenn ich DMXC wieder nutzen möchte. Ob es noch weitere Randbedingungen gibt, versuche ich weiter herauszufinden. Vielleicht reicht aber diese Beschreibung bereits zum Lösen des Problems.

Das Ticket betrachtet das Problem des Verbindungsaufbaus unabhängig zum Ticket FS#4790.