With a newly-loaded show (no manual changes since opened), we have some cues where the following occurs: Load the cue so it is pending, then press GO. The act of pressing GO somehow modifies the show, since the show name is now annotated with an asterisk indicating it has changed since last being saved.
How can this possibly happen? We did modify some of these cues in Blind to ensure that channels with NPs were removed from them.
We're running 2.3.3. And yes, I realize a Blind edit would cause a change. That's not the problem. The issue is that we have a newly-loaded show (from power-on), we load a cue and execute it ( [Cue] 312 [Load] [GO]). As soon as we press [GO], the show file indicates a change. No edits between power-on and [GO].
A deep clear will reset them , much like a software upgrade. If you record a Snapshot, then save the show, then you can recall the snapshot when you reload the show in order to get the screens back to where they were quickly and easily.
They don't execute any macros, and at this point I wouldn't even know how to effect something like that. We don't do anything too fancy (yet). There are several cues that do this (appear to alter the show); many others do not.
I haven't had a chance to get back to the console to try a deep clear. I should be able to try tomorrow.
Sorry for the delayed response. I managed to perform a deep clear, and the show still has the same issue.
I'm open to new recommendations, Sasha. This is frustrating.
Is there any way to determine WHAT the changes are between two versions of a show file (or before a Shift-Update, what the console thinks has changed since loading the show)? If so, it might be possible to deduce what is causing it from that.
Alternatively, I would be willing to send you the show file to see if your team could resolve it.
hey there. Can you send the show file and the logs to eos@etcconnect.com? And if you could paste the link to this forum post in your email, that would be great!
Thanks so much
anne
Hi Lightingdude- thanks for sending in your logs and show file. Thus far I have been unable to duplicate your issue- but I did have a note. I'm not sure your cue list is loaded to the playback correctly. Can you enter [Cue][1][/][Load][Enter] and then resave. After that I am hoping the asterix will stop appearing.
Thanks for your suggestion. Unfortunately, that did not work either. Loaded Cue List 1 using your instructions (Cue 1 / Load; Enter not necessary), then did Shift-Update to save (asterisk gone). Since we nominally use MS 4 for our worship services, we then used our MS 4 button to Load cue 312 ("Load 312"; asterisk still gone). Finally, clicking our MS button GO (tied to the GO function) resulted in the re-appearing asterisk.
We did notice that loading the cue, then pressing the *hard* GO key does not *always* cause the asterisk to show up. However, it did still happen at times, and we could not replicate this one way or the other with consistency.
Clicking the MS macro button, however, always results in the issue.
We're still desperate to work with you for a solution.
I installed 2.4, but we still have the same problem with some of these cues.
If I load the cue, then press Go, then Shift-Update to save, then press Go again, I still get an asterisk. It happens regardless of whether I re-Load or simply advance to the next linked cue.
Examples (executed in sequence):
1. (no asterisk) [Cue] 318.1 [Load] [Go] (asterisk) [Shift]+[Update] (no asterisk) [Go] (to linked cue 319) (asterisk)
2. [Shift-Update] (no asterisk) [Cue] 318.1 [Load] [Go] (asterisk) [Shift]+[Update] (no asterisk) [Cue] 318.1 [Load] [Go] (asterisk)
3. [Shift-Update] (no asterisk) [Go to Cue] 318.1 [Enter] (asterisk)
Something in the execution of these cues (it's not just 318.1 and 319; but it's not ALL of them either) is causing this.
I should point out that when I load the show on etcNomad for the Mac, I can reproduce the issue consistently. So I'm really surprised that you can't recreate it.
I'm about to pose the issue to the Eos Programmer's group on Facebook to see if anyone else has experienced it, but I figured that ETC resources should be able to resolve it.
I know we had corresponded on the Facebook group as well, but to fully close the loop, we fixed aspects of this in 2.4.1, but this should be fully resolved in 2.5.0. The underlying cause was that some channels had null values as the first move in the list (likely created during an import or at some point during editing).
This was certainly an odd one - if it rears its head again, do let us know!
