Watchout display running past pause marker and jumping back

[callum]

Hi all.

Currently installing a Watchout system for projection in a musical, the system consists of 2 display PCs for redundancy and they are controlled via MSC.

I've had 2-3 times now, the display PCs 'run past' the pause marker by about .5 seconds and then jump back to the pause marker. This then causes the free-running video that was active to freeze (which can be rather jaring when the video is of a cast member delivering dialogue).

 

Has anyone seen anything like this before, and if so... what was your solution to prevent this?

The computers have external presonus firestudio pro audio interfaces, not sure if that's relevant given that some software takes clock sync off the audio device.

 

Thanks all! 

[jfk]

Hi all.

Currently installing a Watchout system for projection in a musical, the system consists of 2 display PCs for redundancy and they are controlled via MSC.

I've had 2-3 times now, the display PCs 'run past' the pause marker by about .5 seconds and then jump back to the pause marker. This then causes the free-running video that was active to freeze (which can be rather jaring when the video is of a cast member delivering dialogue).

 

Has anyone seen anything like this before, and if so... what was your solution to prevent this?

The computers have external presonus firestudio pro audio interfaces, not sure if that's relevant given that some software takes clock sync off the audio device.

 

Thanks all! 

 

Yes, I have sen this occur when there are issues with network traffic,

 typically loss of UDP transmissions.

The timeline pause is initially sent from the master via UDP

 and then it is reenforced with a TCP/IP re-transmission.

When UDP is working, the re-transmit has no negative impact.

When it is lost, the results you describe occur.

For testing purposes, disable any additional NICs on your production computer

so that one and only one is active.

If you currently have more than one active NIC (like Ethernet and WiFi, for example)

 this will likely clear it up.

[callum]

Thanks jfk. That’s the current running theory as I saw in the manual they sync via LAN (in show mode there’s no production PC active).

 

We have some KVMs in the network for controlling other gear and they generate a lot of UDP activity (albeit on a different IP subnet). We are going to move these ‘noisy’ broadcast based devices to a different physical network so all we have in the network is the display PCs

[DavidPatrick]

I've also found it can be due to the placement of your cues. This may not be the actual "cause", but separating the pause cue back from the media cue (back the pause cue up .5s for instance) seems to help. This extra time may give Watchout a chance to push / receive the command over the network despite the traffic, and results in the display machines not moving on to the next piece of media.

 

Give it a try. That's usually our workaround when we don't have time to suss a network issue.

[Bluetonesblue]

I have also found the slight offset of PAUSE or PLAY commands from a media cue helpful. If it's close enough to the media, WO will still pre-load the media clip, without triggering it. I especially find this useful on triggering very widescreen videos within it's own Aux timeline with a clean start.

[callum]

Hi All, apologies for the delay.

I just wanted to let everyone know following JFK's reply and talks with the Australian vendor we essentially put it down to some other devices on the network causing too much traffic and moved them off to a totally seperate network. This appears to have resolved this issue.

I also changed some of the programming to put a bit more breathing room between play & pause cues to reduce the impact of it overrunning if it were to ever happen again.