Bugtracker DMXControl 3

Kannst du das Problem genauer beschreiben? Welche Speichern-Funktion hat in welchem Fall deine Änderungen nicht gespeichert?
Bist du dir sicher, dass du die zuletzt gespeicherte Projektdatei verwendest?

jo, hundertpro sicher;) ich habe zwischendurch immer über "strg+s" oder den obersten Button in der linken Seitenleiste gespeichert. es kam auch der übliche Dialog. als ob er keine schreibrechte zum überschreiben der alten projektdatei hätte. bei "save as" als "projektname_v2" gings.

Hallo Micha,

ich glaube, so kommen wir nicht so schnell weiter. Deine Angaben sind nicht eindeutig und widersprechen sich. Einerseits sagst du "am nächsten Tag das Projekt geladen und es war nicht beim letzten Stand." d.h. du hattest Datenverlust. Andererseits sagst du "Es kam mir so vor als hätte ich den Stand vom letzten Save beim Close." = es wurde (wie gewünscht) der letzte Stand gespeichert d.h. du hattest kein Datenverlust

In deinem zweiten Beitrag erwähnst du auch, dass ein erneutes Speichern des Projekts wieder "der übliche Dialog" gekommen wäre. Meinst du den Dialog für die Auswahl des Dateinamens (der wäre unüblich) oder der Dialog mit Fortschrittsbalken, mit welchem die verbundenen Sessions informiert werden, die Affinity.xml komprimiert wird und Co (das wäre üblich). Wenn du immer auch den ersten Dialog bekommst, dann stimmt mit deiner Rechnerkonfiguration irgendetwas nicht - der Dialog wird mir nur beim ersten Mal angezeigt, und dann steht der Dateiname im Titel des DMXControl Fensters.
Wohin speicherst du das Projekt? Tritt der Fehler auch noch auf, wenn du das Verzeichnis Eigene Dateien dafür verwendest?

Kannst du bitte Schritt für Schritt aufschreiben, was du alles nacheinander gemacht hast (welche Knöpfe/Tasten gedrückt), welches Ergebnis tatsächlich auftrat und welches das erwartete Ergebnis gewesen wäre.

Also,
bis jetzt hab ich immer von unterwegs geschrieben, verzeih mir daher die Unverständlichkeit.
Ich gehe nochmal zum Verständnis auf die von mir genannten Speicherarten ein:
1. Speichern per str+s oder Button in der linken Seitenleiste mit anschließendem Fortschrittsbalken (was ich als dialog bezeichnet hatte)
2. Speichern nach Abfrage beim Schliessen des Programmes.
3. "Speichern unter" bei explizitem anwählen der Option, wie bei jeder anderen Software halt auch.

So. Nun zu meinem Hergang:
Ich habe eben mein Projekt geladen, programmiert und getan und zwischendurch immer mit Methode 1 gespeichert. Da ich zwischendurch immer mal wieder neu starte, wegen GUI Lags oder veränderten DDFs schliesse ich also DMXC, drücke beim abschliessenden Dialog (Methode 2) aber auf "nicht speichern" da ich just davor schon "manuell" (Methode 1) gespeichert habe.
Beim erneuten Laden ist der Zustand aber nicht wie beim letzten Speichern nach Methode 1 sondern augenscheinlich wie beim vorherigen Speichern nach Methode 2.
Mit Methode 3 hatte ich auch Erfolg, das hat auf jeden fall gespeichert.
Ich speichere gerade immer auf einen Ordner im Desktop, was ja unter Eigene Dateien fällt.

Ich hoffe ich führe jetzt niemanden auf den Holzweg, ich werde in den nächsten Tagen versuchen das zu reproduzieren.

hi jungs, ich hab jetzt nochmal durchprobiert und die letzten male hat er immer alles gespeichert. Kann es sein dass wenn das projekt noch keinen speicherplatz bekommen hat, also kein erstes mal gespeichert wurde die abfrageroutine beim klicken auf "speichern" nicht immer kommt? trotzdem, ticket kann erstmal raus, vielen Dank!

Bin jetzt bei der Programmierung der Aufführung auch in das Problem reingelaufen... Immer "Speichern unter..." nutzen funktioniert bisher. Sollte also bis zur nächsten Version als Workaround genutzt werden.

Hy,

Interessant. Ich baue mal als 1. Schritt eine Logausgabe ein. Eigentlich gibt es keinen Unterschied zwischen "Speichern unter" und "Speichern". Einziger Unterschied bei Speichern Unter wird ein neuer Dateiname verwendet, bei "Speichern" der alte.

Gruß Arne

Hi Arne,

das Problem könnte durch deinen Fix schon erledigt sein. Du hast die Aufgabe ja am 10.1.2015 geschlossen - die 3.0 kam aber schon davor an Weihnachten raus, also kann die deinen Fix noch gar nicht enthalten. Ich wollts nur für die anderen Nutzer noch mal schreiben, dass ich mit "Speichern unter..." bisher noch keine Probleme hatte. Ich bin mir nicht ganz sicher, aber ich denke ich habe immer den Speichern-Knopf im Hauptfenster genommen, und wegen nem GUI Absturz dann mal DMXControl neugestartet und das (dachte ich) gespeicherte Projekt geladen, und dann hat die teil-programmierte Show gefehlt, das Projekt war einfach auf nem früheren Stand.

Ich hab meine Logs von heute mal nach http://www.dmxcontrol.de/forum/index.php?page=Thread&threadID=10547 hochgeladen, der Fehler trat zwischen 16:01/16:19 Uhr und 17:24 Uhr auf. Weiß nicht mehr wann genau.

Stefan

Hy.

Glaub nicht. Im SVN ist nix zu dem Problem. Der User hat die Schließung angefragt und ich hab das Ticket warscheinlich ungelesen geschlossen. In deinen Logs werde ich nix finden, weil ich hab das Logging erst gerade erweitert, sodass ich evtl. in der nächsten Version was sehe...

Gruß Arne

Hmpf okay, mist.
Du hattest das Ticket damals mit dem Kommentar "Repariert" geschlossen. Eigentlich hab mir mir dann überlegt, ob ich überhaupt noch antworten soll ;) Dann werde ich das mal weiter beobachten.

Ich hab einfach den "Close Request" angenommen. Wahrscheinlich falscher Grund gesetzt.

Sooo, also das Problem ist bei mir heute nochmal (auch mit "Speichern unter...") aufgetreten.
Dass das Problem auftritt erkennt man folgendermaßen:
* Das Speichern-Fenster erscheint
* In der Infozeile erscheint "Informing connected sessions"
* noch ein weiterer Infotext erscheint (weiß ich nicht mehr auswendig...)
* der Text "Compressing Affinity.xml" FEHLT
* weitere Texte wie "Validating" FEHLEN auch

Wenn man hier nicht genau aufpasst, denkt man, DMXControl speichert das Projekt - aber eigentlich speichert DMXControl nichts.
Von daher: Selbst beim Speichern in das gleiche Projekt/Datei schreibt DMXControl nichts, sondern behält einfach die gleiche (alte) Datei bei.

Ich hab dann die GUI geschlossen und versucht, über den Kernel abzuspeichern, aber das hat auch nicht funktioniert - er ist einfach hängen geblieben. Ein funktionsfähiger Kernel beschwert sich, dass er nach c:\ nicht schreiben darf.

Ich vermute, dass bei DMXControl irgendwas abstürzt, man weiter programmieren kann, aber halt die Änderungen nicht mehr speichern - was irgendwie doof ist.

Beim Speichern-Versuch hat DMXControl eine große Datei in sein Kernel-Temp Verzeichnis geschrieben, siehe letzten Anhang.

   Kernel Speichern.png (38,8 KB)
   LumosGUI.log (39,4 KB)
   Lumos.log (258,6 KB)
   Kernel Temp.png (65,5 KB)

Hy Stefan,

Kannst du evtl. die Schritte beschreiben von "Projekt speicher noch" zu "Projekt speichert nicht mehr"?

Hi Arne,

das würd ich gern - aber ich hab "besonderes" gemacht, ich habe:
* StageView verwendet
* Presets angelegt + bearbeitet
* Cues angelegt + bearbeitet
* Cues ausgeführt (normal "Go" und "Go To")
* Fenster-Layout von DMXControl verändert

Also die "normale" Nutzung, die bei der Programmierung auftritt.
Wir hatten zuerst die Generalprobe, während der hab ich an der Cueliste noch ein paar kleine Änderungen gemacht. Die Änderungen konnte ich noch speichern. Dann hab ich weiterprogrammiert, und wollte dann mal wieder Zwischenspeichern - und dann hab ich festgestellt, dass das nicht mehr geht :(
Bisher kann ich also nur sagen: Die Benutzung von DMXControl erhöht die Wahrscheinlichkeit, dass nicht mehr gespeichert werden kann. Konnte noch keine Aktion ausmachen, die das auslöst - so oft speichere ich ja dann auch nicht ;)

Könnte man als Workaround (falls der Bug aus den Logs noch nicht ersichtlich ist) einen Auto-Save jede Minute / alle fünf Minuten einbauen, der sich dann nicht auf die Rückmeldung der GUI verlässt, sondern wirklich überpüft, ob die Datei geschrieben wurde - und falls das nicht der Fall ist sofort ne Fehlermeldung schmeißt: "Achtung, wir ham nen Bug, du kannst DMXControl zwar weiterbenutzen, aber deine Änderungen können erst nach nem Neustart wieder gespeichert werden, letzte Version liegt unter [Pfadname]" - dann hätte man wenig Verlust, und kann sich entscheiden, was man nun tut.

ICh hab den verursacher ausmachen können, und wunder mich gerade extrem über diese codezeile

Lumos\src\Kernel\PropertyValue\IPropertyValue.cs:Zeile 451.

private static readonly NotSupportedException e = new NotSupportedException("This PropertyValue is Readonly!");

void ILumosSaveable.saveToManagedTree(ManagedTreeItem item, LumosIOContext context)
{
    throw e;
}

So, ich hab jetzt erstmal dafur gesorgt, das wenn irgend ein Managet nicht speichern will, er nicht den ganzen vorgang abschießt, sondern er wird dann weggelassn, und schreibt nen Logeintrag.

So wies aussieht kommt das eigentliche problem von den Presets, nur ist der auslöser das das zu speichernde Preset readonly ist oder einen Wert beinhaltet der readonly ist, das könnt ihr ja bitte nochmal testen.
Habt ihr versucht Presets zu kombinieren, das könnte ich mir vorstellen, das das daher kommt.

MfG
Patrick

Hi Patrick,

ich hoffe, du hast die passende Stelle gefunden ;)

Die Programmierung fand für das Stück http://www.dmxcontrol.de/wiki/Singspielarrangement_H%C3%A4nsel_und_Gretel_2015 statt und da habe ich die von Arne in http://www.dmxcontrol.de/forum/index.php?page=Thread&postID=88160#post88160 empfohlene Vorgehensweise umgesetzt und mehrere Presets in eine Cue kombiniert und gespeichert. Geht ja leider nicht anders, da wegen  FS#2174  der wait Trigger kaputt ist - sonst hätte ich nämlich schon die Presets in eigenen Cues nur verlinkt, was den Fehler vielleicht nicht getriggert hätte.

"das könnt ihr ja bitte nochmal testen" → Was genau soll ich denn nun testen? Wir haben "jede Menge gemacht", das kann ich nicht im Detail reproduzieren, was ich über zwei Stunden programmiert habe - und dann nicht speichern konnte. Ich habe da keinen Zusammenhang gesehen. Vorallem, nachdem ich (eigentlich) genau das gleiche dann nochmal gemacht hatte (nur eben schneller, weil's ein zweites Mal dann schneller geht), lies es sich wieder speichern...

Freundliche Grüße

Stefan

Ich hab die stelle gefunden, wo der fehler zum vorscheinen kommt, aber nicht die stelle, wo der Fehler entsteht.

Ich hab jetzt 2 Stunden Presets in jeglicher Form kombiniert und diesen fehler nicht gefunden, ich konnte immer speichern

MfG
Patrick

Hy Patrick,

Mir gings genauso. Die Codezeile über die du dich wunderst ist Absicht. Hier handelt es sich um ein "Readonly" Laufzeit Objekt, dass eigentlich nicht gespeichert werden soll. Der wahre Fehler liegt darin, dass dieses Readonly Objekt irgendwo erzeugt wird. Leider hab ich nicht herausgefunden wo. Das müssen wir finden, alles andere wäre murks.

Hilft nur weitersuchen.

Gruß Arne

Moin!

Heute hat mir DMXControl leider auch diesen Streich gespielt, nachdem ich zusammen mit der künstlerischen Leitung den kompletten Lichtablauf für ein Theaterstück zusammengestellt habe. Ihr könnt bestimmt nachvollziehen, dass ich am liebsten in den Tisch gebissen und laut Schei...benkleister geschrien hätte. Aber gut, ist jetzt nunmal so.

Folgendes habe ich vor dem gescheiterten Speichern gemacht:
- Presets angelegt
- Presets angepasst
- Presets in Cues abgespeichert
- Cuelisten abgespielt
- Mit Stageview, PropertyGrid etc. gearbeitet

Was ich nicht gemacht habe, ist das Kombinieren von Presets gemäß http://www.dmxcontrol.de/forum/index.php?page=Thread&postID=88025#post8802. Das scheint also nicht der, oder zumindest nicht der einzige Trigger für den Fehler zu sein.

Gearbeitet habe ich an einer GUI, die per Netzwerk mit einem Kernel auf einem anderen Rechner verbunden war. Auf dem Kernelrechner lief, wenn ich mich nicht irre, ebenfalls eine GUI. Nachdem der Fehler aufgetreten war, fiel mir noch auf, dass beide GUIs wesentlich träger reagierten als zuvor.

Beste Grüße
Henrik

   dmxc3speicherfehler.png (262,3 KB)
   DMXControl3Logs_2015519_1791.... (101,1 KB)

Ich konnte den Fehler gerade reproduzieren. Nach dem ersetzen eines Presets mittels "Replace" funktioniert das Speichern bei mir momentan generell nicht. Das Preset ist dabei in einer Cueliste verknüpft. Nach Neustart von Kernel und GUI und mit dem alten Projektstand beginnt das Spiel von vorne.

Grütze, das kann ich heute am VA-Tag ja richtig gut gebrauchen..

Passiert nicht nur bei Replace, sondern auch bei Merge. Um mehr zu testen, habe ich jetzt keinen Bock und keine Zeit.

Danke fürs Melden. Ja, Presets, die in Cues verwendet werden, hatte ich auch ersetzt.

Aber ich habe das gerade mal mit deinen Angaben für eine Dimmergruppe und eine Gruppe mit zwei Movingheads probiert, aber trotzdem lässt sich das (angehängte) Projekt problemlos speichern. Vielleicht verwende ich andere (weniger) Eigenschaften oder Geräte als du?

Kopier dir das Projekt in dem Zustand irgendwo hin, und merke dir genau, was du tun musst, um den Bug zu triggern. Dann können wir ihn hoffentlich reproduzieren! Danke schon im Voraus.

   Save_Bug.zip (757,1 KB)

Ich habe gerade auch mal mit einem frischen Projekt getestet und konnte den Bug so ebenfalls nicht reproduzieren. Das Projekt, mit welchem ich das Problem reproduzieren konnte, kann ich leider gerade nicht testen, da einige DDFs nur auf den Rechnern in der Schule liegen, und ich gerade wenig Lust habe da noch mal hinzufahren, da war ich die letzten Tage schon oft genug :) Das muss bis morgen warten. Ich bin aber eigentlich zuversichtlich, damit den Bug reproduzieren zu können. Ich hatte auch extra noch mal einen Zwischenstand in Sicherheit gebracht, bevor ich größere Anpassungen gemacht habe. Der liegt aber auch noch auf einem der Rechner in der Schule.

Falls ihr noch Logs für diesen Fehler braucht, konnte ich ihn gerade ebenfalls reproduzieren. Ich war mir nicht mehr sicher, ob das Verändern eines Presets, in dem eine Position gespeichert ist, sich auf eine Cue auswirkt, in der das Preset als Mittelpunkt für eine Bewegung verwendet wurde (es wirkt sich übrigens nicht aus - ich denke beim Hinzufügen eines Effekts wird der Positionswert überschrieben).

Folgendes habe ich dafür getan:
1. Ein paar Devices angelegt und gespeichert über das Speichern-Symbol.
2. Zwei Presets mit zwei unterschiedlichen Positionen angelegt.
3. Eins der beiden Presets angewandt, einen Bewegungseffekt hinzugefügt und als Cue abgespeichert.
4. Eine dritte Position im Programmer erstellt und mittels Replace, das verwendete Preset überschrieben.
5. Gespeichert über das Speichern-Symbol.
6. DMXControl geschlossen und nicht erneut gespeichert.

Beim Laden des Projekts wird der Stand nach Schritt 1 geladen. Die Presets und die Cues fehlen.

Während dieser Schritte gab es im Logs-Fenster zwei Fehlermeldungen, die ich nicht deuten konnte. Diese sollten in der vorletzten Session der Logs zu finden sein. Ich hoffe, das hilft weiter.

   DMXControl3Logs_201597_8227.z... (226 KB)

Ach ja, sorry das ich mich hier nicht mehr gemeldet habe. Den Projektstand, mit dem ich das Problem im Juni reproduzieren konnte, habe ich leider nicht mehr. Ich habe damals im Eifer des Gefechts (ich stand etwas unter Zeitdruck) leider nicht daran gedacht, die Datei rechtzeitig in Sicherheit zu bringen. Mein Fokus lag halt leider darauf, die Show irgendwie an den Start zu bekommen ;)