- Status geschlossen
- Prozent erledigt
- Aufgabentyp Fehlerbericht
- Kategorie GUI & Server
- zuständig niemand
- Betriebssystem All
- Schweregrad niedrig
- betrifft Version 3.3 Alpha x
- fällig in Version unbestimmt
-
fällig am
unbestimmt
- Stimmen
- versteckt
angelegt von LightningBrothers - 15.11.2021
zuletzt bearbeitet von Qasi - 22.01.2022
FS#4657 - Tracking ignoriert "Back"-Button vom Executor
Ich habe mir eine Cuelist mit fünf Cues gebaut, wobei das Tracking standardmäßig aktiv ist:
- Cue 1 - blue > red
- Cue 2 - static white
- Cue 3 - green > blue
- Cue 4 - static red
- Cue 5 - static violett
Mit dieser Cuelist führe ich folgende Schritte aus:
- Ich lasse die manuell via Go getriggert per Executor bis zur 5. Cue durchlaufen.
- Ich drücke mehrfach den Pause- / Back-Button. Die Anzeige unter “Current cue” springt ab dem zweiten Klick mit jedem weiteren Klick Cue für Cue zurück - und zwar in der Reihenfolge, wie die Cues in der zugeordneten Cuelist angeordnet sind. Den Button drücke ich so lange, bis unter “Current cue” die “Cue 2” aufgeführt wird. Die Zeile ist grau hinterlegt.
- Ich klicken auf Go. Der blaue Balken beginnt, sich von links aus aufzubauen. Das gleiche Verhalten zeigt die Cuelist selbst auch.
Mit dem Klick auf Go führt die Cuelist aber nicht wie vom Executor suggeriert die “Cue 2” aus, sondern die der “Cue 5” vorhergehende “Cue 4”. Erst wenn ich das Tracking deaktiviere wird auch die “Cue 2” tatsächlich ausgegeben.
An dieser Stelle sollte ich aus meiner Sicht die Cuelist nicht anders verhalten, als wenn ich die “Cue 2” in der Cuelist selbst manuell per “Load” vorauswähle und dann mit dem Klick auf Go (egal ob Cuelist oder per Executor) aufrufe. Sprich: in beiden Fällen (egal ob Tracking aktiv oder nicht) sollte die “Cue 2” ausgeführt werden, so wie es mir auch in der Anzeige im Executor oder in den Progress-Balken der Cuelist suggeriert wird.
Um das unterschiedliche Verhalten darzustellen, enthält das beigefügte Projekt die Cuelist zwei Mal - einmal mit aktiven und einmal mit deaktiviertem Tracking. Beide Cuuelists sind direkt per Executor aufrufbar, wenn das letzte Fensterlayout geladen wird.
Also wenn ich das richtig lese, ist das Verhalten der Cueliste erstmal i.O, nur die visuelle Darstellung im Executor stimmt nicht. Korrekt?
Wenn ich "Go back" direkt über die Cuelist ausführe, arbeitet alles wie erwartet. Die Cues werden von unten nach oben ausgegeben.
Es ist ein Kommunikationsproblem zwischen Executor und Cuelist in Verbindung mit dem Tracking. Führe ich die oben beschriebenen Schritte in der Cuelist "Tracking on" aus, gehe aber per "Pause / Back" nicht bis zur Cue 2 sondern bis zur Cue 1 zurück, sehe ich
Bei der Cuelist "Tracking off" wird
Ich denke, das Phänomen ist wie gesagt am besten mit dem Beispielprojekt nachzuvollziehen. Ich hatte jetzt keine Lust (mehr) ein Video zu drehen - was mir vielleicht rückblickend doch einiges an Text gespart hätte. Aber ich kann ja meine Meinung noch ändern.
Ich weis immernoch nicht was nicht geht.
Im Kernel ist absolut kein unterschied, von wo das GoBack getriggert wird, den es ist immer ein und die selbe methode
So… Ich habe mal mit dem bereits oben beigefügten Beispielprojekt nun doch noch ein Video gedreht.
Warum wurde das wieder geöffnet?
Ich hatte mich verklickt und das falsche Ticket geschlossen. Das Ticket hier ist valide. Das geschlossene Ticket ist
FS#4669häääääääää ich verstehs nicht!
Bullshit, das ist
FS#3605.Der Progress voren wird falsch angezeigt
Ich habe das gerade mal geteset und genau so gemacht wie Stephan, bei mir passiert aber in der Beta 6 noch das gleiche wie bei Stephan, ist also nicht repariert, oder?