FLX Tracking Backup

[scottydog75]

Hi all,

I'm currently running a show where I've hired in another FLX as a tracking backup, as I can't afford any crashes during the run.

This is the first time I have ever tried setting up tracking before, and I was testing it during the dress rehearsal last night.

As per the guide https://www.zero88.com/manuals/zeros/setup/devices/tracking-backup I have made sure that each desk is on a separate IP and they were communicating with each other (using Art-Net).

What was strange was that the backup desk kept taking control every so often without the prompt or need to do so.

I have made an assumption that it is doing this because I was updating the cue stack on the main desk, and then it is pushing this update across to the backup desk. The backup desk then thinks it is running a newer show file than the main desk, and therefore takes control - however I could be misinterpreting this, and some other weird network force could be at play?

Does anyone have any reliable experience with tracking backup, and may be able to provide any pointers? Will this be more reliable once I stop making updates to the cue stack - which I am unlikely to be doing so during the actual show (opens tonight!)

Many thanks

[Archie D]

Hi @scottydog75,

Tracking backup ensures that the master and backup desk(s) are synchronised - so when an update is made on the master desk (e.g. a cue is recorded, a playback is raised), it is automatically transferred to the backup desk without any prompts.

Therefore, making edits to the showfile on the master desk shouldn't force the backup desk to take over. You'd get a prompt (as seen below) asking which show file you want to use when taking back control on the master desk if the backup desk has already taken over, along with the ability to save the current showfile on that desk to a USB storage device.

At the time, were you using DHCP, or did you assign the desks static IP addresses? Perhaps something was conflicting with the master desk using static IPs, meaning the master desk couldn't acknowledge the backup desk to say 'Yes, I'm still here!', therefore the backup desk took over?

Or, perhaps some packets were lost over the network and again, the backup desk couldn't pick up that the master desk was still alive...