• State Suggested Answer
  • Date
    krymy
  • Date
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 187 subscribers
  • Views 50 views
  • Users 0 members are here

Saving on master/backup

Hi, i have just had an interesting thing happen and I'm unsure if it's a bug or expected behavior that I have never encountered before.

We usually run RPU master and Apex 10 backup.
Right now, the rpu is away for repair so I set the Apex as master and connected a Nomad as backup.

When I disconnect the master and the backup takes over everything is working fine. When I reconnected the master and take back control it works fine. But when I try to shift+update it looks like it's saving but when looking closer the file path is still showing to the show file archive on the Nomad. And the backup does not save so no file is actually saved before I do a save as.

Is this Expected or somthing wrong?


I'm on software 3.3.4

Parents
  • 0

    Hi krymy. this is a bug that has been going on for quite some time.

    I found this bug the hard way when one week of lighting rehearsals went missing. the monday after a weekend full of shows.

    The issue is that when taking back control from a Nomad system, the console doesn't correctly map the path for saving showfiles. It looks like it is saving to your nomad PC with the path C/[Desktop Name]/Documents/ETC/eos... but what its actually doing is creating this folder structure on your desk locally. So on your consoles C: drive its actually creating a folder with [Desktop Name]/Documents/ETC/eos and so on where its then saving the showfile to, every time you shift update. 

    The big problem with this is that the C: drive is by default hidden from the user and can only be accessed with a few hacks in the shell to get to the underlying Windows 7 Embedded (In your case Win10) file system. If you've lost some important progress on a showfile this way, reach out to ETC support and they will help you to get into the hidden C: drive to recover the showfiles.

    There are two fixes that i currently know of to fix this wrong mapping. On your console, you can [save as] which will overwrite the wrong path. 
    The second method (i like this way more) is to just Shift update on your backup, once the master took over control. this way, the showfile is saved and the correct mapping is also restored on the master. 

    ETC Tech support Germany is aware of this issue. I'm not sure if this was passed down internally to get fixed. I first found this on v3.2.10 back in spring of 2025. Hoping this gets fixed in the future.

    hope this helps.

Reply
  • 0

    Hi krymy. this is a bug that has been going on for quite some time.

    I found this bug the hard way when one week of lighting rehearsals went missing. the monday after a weekend full of shows.

    The issue is that when taking back control from a Nomad system, the console doesn't correctly map the path for saving showfiles. It looks like it is saving to your nomad PC with the path C/[Desktop Name]/Documents/ETC/eos... but what its actually doing is creating this folder structure on your desk locally. So on your consoles C: drive its actually creating a folder with [Desktop Name]/Documents/ETC/eos and so on where its then saving the showfile to, every time you shift update. 

    The big problem with this is that the C: drive is by default hidden from the user and can only be accessed with a few hacks in the shell to get to the underlying Windows 7 Embedded (In your case Win10) file system. If you've lost some important progress on a showfile this way, reach out to ETC support and they will help you to get into the hidden C: drive to recover the showfiles.

    There are two fixes that i currently know of to fix this wrong mapping. On your console, you can [save as] which will overwrite the wrong path. 
    The second method (i like this way more) is to just Shift update on your backup, once the master took over control. this way, the showfile is saved and the correct mapping is also restored on the master. 

    ETC Tech support Germany is aware of this issue. I'm not sure if this was passed down internally to get fixed. I first found this on v3.2.10 back in spring of 2025. Hoping this gets fixed in the future.

    hope this helps.

Children
Related

www.etcconnect.com