Bugtracker DMXControl 3

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

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

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

Der Pfad zur MEVP.dll wird im Ausgabeplugin zwar übernommen, gespeichert und ist nach dem Neustart ebenfalls vorhanden. Aber irgendwie fehlt der Verweis auf die MEVP.dll, da ich im Ausgabeplugin nur den reinen Pfad angebe und (gefühlt) nicht mehr wie in einer der vorherigen Versionen auch den Namen der DLL mit eingebe. Dies hat zur Folge, dass Easy View trotz aktiviertem Interface und DMX-Out nicht starten mag.

Verschiedene DMX-Interfaces, wie zum Beispiel das Nodle U1 oder das Nodle R4S werden nach dem Beenden des Kernels nicht automatisch abgeschaltet, wenn diese zuvor aktiv waren. Die Status-LEDs gehen nicht aus.

Folgendes Vorgehen:

1. ArtNet-Plugin einmal hinzufügen und einrichten
2. ArtNet-Plugin mit Checkbox in erster Spalte deaktivieren
3. ArtNet-Plugin mit Checkbox in erster Spalte wieder aktivieren

Nun taucht im Kernel folgender Eintrag alle 3 Sekunden auf:

23:26:37 ERROR ArtNetFactory - ArtPollReply shorter than 239 bytes, ignoring!

Deaktiviert und aktiviert man das Plugin erneut, werden nun alle 3 Sekunden 2 Einträge hinzugefügt, usw.

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

Ich habe mir ein Projekt erstellt, um die verschiedenen Executor-Typen zu testen und zu dokumentieren. Die Belegung der verschiedenen Seiten ist in den beigefügten Screenshots zu sehen. Die verschiedenen Executoren enthalten dabei auf allen Seiten mehrfach die gleichen Elemente, damit ich insbesondere auch die zahlreichen Buttons prüfen kann. Soweit ich das überblicke, werden diese Informationen auch richtig in die Datei “ExecutorMemberWrappers.xml” geschrieben.

Beim erneuten Laden des Projekts direkt aus der laufenden Sitzung heraus oder auch beim Laden des Projekts nach einem Neustart von DMXC werden die Belegung der Executor-Pages augenscheinlich unvollständig bzw. gar nicht geladen - insbesondere bei den “hinteren” Executor-Pages (im aktuellen Beispiel Group Master, Parameter Master etc.). Beim Betätigen des Faders des Executor 2.1 (Executor Page Group Master) kann man aber erkennen, dass eine Verknüpfung im Hintergrund noch existiert. Die Fader der Executoren 2.2 und 2.3 bewegen sich mit. Gleiches fällt auf, wenn man die Belegung der Executoren ändern möchte. Es wird erst beim zweiten Ablegen eines Elements auf den Executor wirklich das neue Element angezeigt.

Im Anhang findet sich neben den Screenshots des Sollzustands das zugehörige Projekt sowie die Logfiles, die nach dem Neustart und Laden des Projekts generiert wurden.

Öffne ich das Projekt aus  FS#4656  und starte dann einmal nur die GUI neu, ist das Executor-Fenster komplett leer. Es werden sowohl keine Executor Pages als auch die Executoren selbst nicht angezeigt.

Klicke ich aber auf “Add Page”, merkt das Fenster, dass bereits Executor Pages im geladenen Projekt existieren und beginnt entsprechend nach dem “höchsten” Executor zu zählen. Auch die Seitenzahl beginnt nicht bei 1.

siehe Titel

Aktuell gibt es in den Einstellungen für den Executor zu den Cuelists noch den Eintrag “Release at zero”. Dieser funktioniert nicht und wurde mittlerweile durch “Auto Stop” abgelöst.

Der neue Fadertyp “Limit” für die Executor-Variante der Cuelist ist in den Einstellungen des Executors noch nicht in der Auswahlliste für den Fader enthalten.

Wird ein Button eines Executors als Flash-Button definiert und anschließend über das IA getriggert wird der Executor zwar geflasht aber auch noch nach dem loslassen des Inputs, d.h. es ist nicht möglich in den Eingang Button 1/ Button 2 usw. zu gehen und dann zu flashen da dieser Zustand nicht beendet werden kann.

Einstellungen zu den Exeucotren werden nicht vollstdänig geladen, konkret wird nur “Name” und “Nummer” als Einstellungsmöglichkeiten angezeigt.

Logs im Anhang.

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.

- DMXControl Starten, leeres Projekt
- Neues Device (getestet mit Generic RGB + Eurolite PS-4 HCL)
- Stageview, Properties von Device
- Default Color wählen
- Lumos Drücken

Ergebnis:
- In Color-Picker + Device Control ist die Farbe gesetzt
- In Stage View, Programer + DMX Ausgabe wird weiß angezeigt.

s.o.

Wenn man eine Cue per Input Assignment startet, während die entsprechende Cuelist nicht geöffnet ist, und anschließend die Cuelist öffnet, ist die aktive Cue nicht gelb markiert. Die Cuelist wird im Cuelist Editor so dargestellt, als ob sie nicht aktiv wäre.

Ich wollte verschiedene Power Sources in Ordnern ablegen. Sobald im Project Explorer auf Refresh klicke, laden diese wieder auf der obersten Ebene, während der Baum noch die gewünschte Zuordnung suggeriert.

Hinzu kommt hierbei auch, dass der geänderte Name nicht übernommen wurde. F409 sollte mittlerweile T1-F409 heißen.

Im Affintiy Manager werden die Icons der Gobos im linken Teil des Fensters nicht nach Namen sortiert. Dies erschwert das Aufsuchen von bestimmten Icons. Ggf. wäre darüber nachzudenken, ob hier per Default sowieso nur die Icons angezeigt werden, die aktuell im Projekt auch im Einsatz (entweder über die DDFs oder durch Gobolists) sind.

Im folgenden Setup kann die GUI des PC 2 die Einstellungen wie zum Beispiel die Änderung der Sprache nicht speichern.

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

Die GUI auf PC 2 stürzt dabei komplett ab, sobald ich diese regulär schließe. Aktuell hilft es nur, wenn ich auf dem PC 2 Kernel und Umbra lokal starte und somit für die Änderung ein komplett autarkes System habe.

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

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

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

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

Sowohl die Menüleiste des Input Assignment selbst als auch das Kontextmenü der Graphenansicht (hier erste Ebene) entspricht nicht der sonst üblichen Größe. Dadurch sind die Icons in beiden Fällen unscharf, was auch beim direkten Vergleich mit der Menüleiste des Project Explorers gut zu erkennen ist.

Im ähnlichen Kontext steht auch das Ticket  FS#4448 .

Aktuell werden die Buttons für ABS und REL im Device Control nicht angezeigt. Die Breite des Property Grids entspricht aber bereits der neuen Breite.

Ich kann unter einer neuen Itemlist aktuell noch keine Positionlist anlegen.

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

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

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

Beim Sichten der GUI-Logs zum Ticket  FS#4506  ist mit folgender Eintrag beim Shutdown-Prozess aufgefallen:

2021-04-26 20:02:06,996 [Main GUI] ERROR Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei Lumos.GUI.Themes.ThemeManager.checkCorrectFontUnit(Control parent) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 212.
   bei Lumos.GUI.Themes.ThemeManager.SetThemeInAllControlsTools(Control parent, AbstractGUITheme theme) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 316.
   bei Lumos.GUI.Themes.ThemeManager.Parent_ContextMenuStripChanged(Object sender, EventArgs e) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Theme\ThemeManager.cs:Zeile 435.
   bei System.Windows.Forms.Control.OnContextMenuStripChanged(EventArgs e)
   bei System.Windows.Forms.Control.set_ContextMenuStrip(ContextMenuStrip value)
   bei System.Windows.Forms.Control.DetachContextMenuStrip(Object sender, EventArgs e)
   bei System.ComponentModel.Component.Dispose(Boolean disposing)
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ToolStrip.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContextMenuStrip.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.ComponentModel.Container.Dispose(Boolean disposing)
   bei System.ComponentModel.Container.Dispose()
   bei Lumos.GUI.Windows.InputLayer.v2.InputLayerForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\InputLayer\v2\InputLayerForm.Designer.cs:Zeile 24.
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Dispose(Boolean disposing)
   bei WeifenLuo.WinFormsUI.Docking.DockPane.Close()
   bei WeifenLuo.WinFormsUI.Docking.DockPaneCollection.Dispose()
   bei WeifenLuo.WinFormsUI.Docking.DockPanel.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.ContainerControl.Dispose(Boolean disposing)
   bei System.ComponentModel.Component.Dispose()
   bei System.Windows.Forms.Control.Dispose(Boolean disposing)
   bei System.Windows.Forms.Form.Dispose(Boolean disposing)
   bei Lumos.GUI.Windows.MainForm.Dispose(Boolean disposing) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.Designer.cs:Zeile 22.
   bei System.Windows.Forms.Form.WmClose(Message& m)
   bei System.Windows.Forms.Form.WndProc(Message& m)
   bei Lumos.GUI.Windows.MainForm.WndProc(Message& m) in D:\Jenkins\workspace\Lumos_Pipeline_master\LumosGUI\src\Windows\MainForm.cs:Zeile 531.
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Fehlerbeschreibung

Die Master werden in der Reihenfolge 1, 10, 11, 2, 3, 4, 5, 6, 7, 8 ,9 dargestellt, zum schnellen finden wäre eine normale Sortierung praktischer.

Kann der Kernel ein Projekt nicht speichern, weil es durch andere Anwendungen schreibgeschützt ist oder nicht gefunden werden kann, erhält der Nutzer keine Info mehr darüber. Hier sollte unbedingt eine Fehlermeldung in der GUI erscheinen, wie es auch aktuell in DMXC 3.2.x der Fall ist.

Ist in einem DDF ein nicht rotierbares Goborad definiert, ist im Gobo Device Control Fenster trotzdem der Fader für die Rotation anwählbar bzw. veränderbar.
Dieser müsste eigentlich grau hinterlegt sein.
Ein Verstellen des Faders hat (logischerweise) keine Auswirkung auf die DMX Ausgabe.

Ist im DDF hingegen ein statisches und ein rotierbares Goborad definiert, ist der Rotationsfader vom statischen Rad ausgegraut.
Hier funktioniert alles wie es soll.

Nico

Ich habe ein Gerät mit einer 1×6 Matrix (6 Pixel horizontal in einer Zeile). Ändere ich hier die Ausrichtung der Matrix oder möchte diese auf einer Ebene spiegeln, friert die GUI ein. Nach dem Abschießen der GUI lässt sich der Kernel daraufhin auch nicht mehr per Kommandozeile vollständig herunter fahren.

nicht vorhanden

An aktuell zwei Stellen ist mir aufgefallen, dass das Anzeigeformat unter den folgenden Punkten noch fortlaufend ist und nicht wie angedacht im Format [Universum.Adresse].

• Konfiguration der DMX-Interfaces: nach dem Aktualisieren der Liste (siehe Bild 1)
• Add device dialog: im Projekt existieren bereits Geräte und man fügt zu einem späteren Zeitpunkt weitere hinzu (siehe Bild 2)

An weiteren Stellen, wie zum Beispiel in den Device Properties oder im Patching Dialog werden die DMX-Adressen im gewünschten Format [Universum.Adresse] angezeigt.

Ich habe zwei DMX-Interfaces hinzugefügt und diese dann deaktiviert (siehe Bild 1). Aktualisiere ich die Ansicht, werden zwar beide Interfaces durch die grau hinterlegten Zellen als deaktiviert gekennzeichnet (siehe Bild 2). Der Haken wird aber wieder gesetzt, was dann zu Verwirrung führt.

Dieser Fehler steht aber nicht im Zusammenhang mit Ticket  FS#3864  bzw. darf nicht als solcher verstanden werden.

Im Anhang die Log-Dateien der Sitzung.

siehe bild

Das Problem aus dem angehängten Bild taucht im SoftDesk auf, wenn der Softdesk größer als der Designer ist.

In den Optionen für die Cuelist Group ist der Eintrag “Intelligent settings” wieder sichtbar. Da diese Funktion nicht genutzt werden soll und auch nicht genutzt werden kann, müsste die einmal ausgeblendet werden.

Öffne und schließe ich den Image chooser mehrfach in einer Sitzung, um Gobos für eine Gobo list oder für die Gobo affinity auszuwählen, reagierte die GUI nach einigen Malen nicht mehr und im Log erscheint folgender Eintrag

2022-04-15 13:05:18,330 [Main GUI] ERROR Lumos.GUI.App - Exception in WPF
System.OutOfMemoryException: Eine Ausnahme vom Typ "System.OutOfMemoryException" wurde ausgelöst.

In diesen Fällen beendet sich die GUI selbst und muss manuell neu gestartet werden.

Die vollständigen Logs stelle ich zu einem späteren Zeitpunkt zur Verfügung, wenn ich das Problem nochmal gezielt reproduziere.

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

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

Möchte ich im Programmer Filter Devices / Device Groups abwählen bzw. anwählen, dass ihre Werte (nicht) in einer Cue abgespeichert werden, so ist dies nur über einen Rechtsklick in die Checkbox möglich. Der Linksklick funktioniert nur einmalig, wenn ich zuvor einen Eintrag in den Properties des zugehörigen Devices / Device Groups geändert habe.

Das Ab- und Anwählen von Properties der Devices / Device Groups funktioniert dagegen durchgängig per Linksklick.

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

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

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

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

Die Nodes im Input Assignment haben seit der Beta keine Properties mehr. Siehe hierzu exemplarisch das Bild des Draw Bitmap Nodes.

Fehlerbeschreibung

Fehlerbeschreibung

Ich lade ein etwas größeres Projekt, wo DMXC auch ein bisschen mit zu tun hat (große Anzahl an Geräten und Cuelists, einige Connectionssets im Input Assignment). Dabei passiert es regelmäßig, dass die Project Administration im Hintergrund verschwindet und ich das Fenster erst explizit über die Taskleiste in den Vorgrund holen muss, um weiterarbeiten zu können.

Es macht keinen Unterschied, ob ich das zuletzt gespeicherte Fensterlayout aufrufe oder nicht. Ebenfalls hat die Einstellung “Show taskbar icon for each window” ebenfalls keinen Einfluss, ob das Fenster nach dem Laden des Projekts im Hintergrund liegt oder nicht.

Speichere ich mein Projekt, so wird in der Project Administration die UTC-Zeit der letzten Sicherung anzeigt, wodurch ich somit eine Verschiebung von zwei Stunden habe (siehe Screenshot).

Da sich Kernel und Umbra ebenfalls in ihren Logs auf die Systemzeit berufen, sollte es bei der Project Administration nicht anders sein oder automatisch die Zeitzone inkl. Sommer- / Winterzeit des PCs ausgelesen werden, auf dem der Kernel läuft.

Ändere ich an mehreren Projekten den Status, ob dieses Projekt angepinnt sein soll oder nicht, wird mir dies spätestens ab dem zweiten Klick auf den Button nicht mehr richtig dargestellt. Um herauszufinden, wie der Status meiner Projekte ist, muss ich die Project Administration einmal schließen und erneut öffnen.

Logfiles kann ich nicht zur Verfügung stellen, da diese Aktion nicht protokolliert wird.

2022-10-13 23:33:17,963 [54] FATAL Lumos.GUI.Run.GuiRunManager - Unhandled Exception: Die Sequenz enthält keine Elemente.
System.InvalidOperationException: Die Sequenz enthält keine Elemente.
   bei System.Linq.Enumerable.First[TSource](IEnumerable`1 source)
   bei Lumos.GUI.Windows.Project.ViewModels.ProjectListItemViewModel.<Create>d__6.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Project\ViewModels\ProjectListItemViewModel.cs:Zeile 73.
--- 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 System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   bei Lumos.GUI.Windows.Project.ViewModels.ProjectAdministrationViewModel.<Client_ProjectChanged>d__11.MoveNext() in D:\Jenkins\workspace\Lumos_Pipeline_3.3\LumosGUI\src\Windows\Project\ViewModels\ProjectAdministrationViewModel.cs:Zeile 102.
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
   bei System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_1(Object state)
   bei System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()
   bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

In dem beigefügten Projekt habe ich eine Reihe unterschiedlicher Master angelegt und zwar in folgender Reihenfolge:

• Group Master (beim Patching)
  • MIS Group
  • DMH Group
  • AX5 Master
• Parameter Master (über Device Control)
  • Parameter Master 1 (Default)
  • Parameter Master 13
  • Parameter Master 8
• Speed Master (über Device Control)
  • Speed Master 1 (Default)
  • Speed Master 6
  • Speed Master 4
  • Speed Master 7
  • Speed Master 3
• Color Master (über Device Control)
  • Color Master 1 (Default)
  • Color Master 21
  • Color Master 14
  • Color Master 3
  • Color Master 31

Meine Erwartungshaltung wäre an dieser Stelle, dass die Master eines jeden Typs (insbesondere die Parameter Master, Speed Master, Position Master und Color Master) nicht pauschal in der Reihenfolge sortiert werden, wie ich sie erzeugt habe, sondern

• Alphabetisch (bevorzugt)
• Anhand der Nummer des Masters

Das aktuelle Ergebnis des nicht wirklich sortieren Zustands (auch nach dem Speichern und Laden des Projekts) ist im beifügten Screenshot zu sehen.

Erweitere ich einen Group Master über die Pfeile, dann erscheint ein weiterer Regler für den Group Master, wie im beigefügten Screenshot zu sehen.

Dies ist an dieser Stelle soweit unnötig, da er das gleiche tut, wie der Regler, der die ganze Zeit bereits zu sehen ist.