It's not actually in an Aux timeline. The program is set to start when it loads, and the video cues are on the Main timeline. The cues are set to loop and free run, then the timeline pauses. The video cue starts at about 4 seconds, and I had the timeline pause cue at about 6 seconds in. I have stretched out the video cue moved the pause cue so that it occurs at about 2 minutes in, that way there should be no issues with the slave computers not being ready before the pause.
What I see happening, and why I thought it relevant, is if the master computer has reached a pause in the timeline before the slave computers have loaded, the slaves load and jump to the point where the pause cue sits. But since they didn't "run" to get there, the video doesn't start. The initial description was that the master computer played free running and looping video fine, but the slaves didn't and instead just show a still frame.
Thanks for clearing that up.
There are two causes for that issue.
If I understand correctly, you are using a startup script to autostart the show.
That rules out cause number 1. (Loss of, or, Failure to establish a valid, cluster master).
2. You may have a network issue with UDP multi-cast.
Transport commands to cluster members
are sent via UDP multi-cast from the cluster master.
But it appears the members are not receiving them.
broadcast commands have no handshake, as they are time sensitive.
When a pause is encountered, the master sends a gotoTime update via TCP/IP,
as a sort of redundant re-synch with the addition of the TCP/IP handshake.
If all is working right, you will not see it.
When the UDP transport commands do not get through,
all you are seeing is the redundant re-synch sent via a different path, so to speak,
which are the jumps you are seeing.
Be aware of switches with Denial of Service (DOS) attack protection from UDP flood or UDP storm.
This network safeguard can affect watchout after a few minutes of normal operation.