Issues with Display cluster syncing

[Dill]

Hello,

 

I do have some syncing issues with my display computers. They are 5 Display Computer in one Cluster with IPs 151 to 155. 151 should be the Displaymaster.

 

First I may ask for the behavior, if the display master ist starting with a startup script, but later get connected and controlled by a production computer. Is this possible without any issues?

 

At the moment there are three ways to control the cluster here.

 

1. Startup script and the cluster controlled by external LTC

The startup script, only loaded from the display 151:

 

authenticate 1

wait

load “show”

wait

timecodeMode 6

 

Going this way, often the external LTC can only control the display master, ignoring the other display computer.

 

2. By production computer.

Here sometimes after going online, The displays of the main display computer 151 are showing an red x and are not reachable. Only the other display computer are controllable.

 

Going OFF- and ONLINE several times fixes this most of the time.

No Messages under production Messages.

 

3. Sending a TCP String from the Production Computer while offline, giving the display master the command to load the show and going into timecodeMode.

 

authenticate 1$0D

wait$0D

load “show”$0D

wait$0D

timecodeMode 6$0D

 

giving the same results as with the production computer being online, but most times the master is the only one in control. even if there is a flickering in the other displays, indicating that the show was loaded and synced on all display computer. Sometimes it starts syncing with the LTC initially but isn't controlled by it anymore running on even the LTC is stopped (Checked that doubled, no freerun issue).

 

If going online with the production computer after sending the command to the master, often the following error messages appear:

 

https://s12.postimg.org/iv67h23sd/messages.png

 

 

 

All these issues are not always reproduceable. But most of the time it's not working as expected.

 

Is there any solution to this?

 

Thanks

Dill

[jfk]

Bit much to follow, but it appears to be a common misunderstanding on 

what truly defines a cluster "master".

There is only one way to define a master, and that is the load command.

Connecting to the computer and sending other commands does not make it the master,

 only the load command does that. The last valid load command to any member of the cluster group

is the only one that matters, as this re-establishes the cluster again.

 

Anyway, anytime you use Production, it sends the load as part of going online,

making it the new master.

Go back to cluster commands, and even though the show is loaded,

if you do not send the load again to establish the new master,

then only that one computer you are connected to will respond.

(When you do send the load to a computer with the show already loaded,

it will pause, but it will maintain its current position.)

 

 

I see you mention the load, possibly your issue is the other common problem, blocked UDP.

 

With blocked UDP (commonly a result of a switch's UDP flood / UDP storm protection

thinking the WATCHOUT continuos broadcast is a Denial Of Service attack),

some functions will work as they are sent TCP/IP (load, gotoTime, etc)

and others will not (transport commands, etc.).

[Dill]

Hello jfk,

 

tried some things with the network infrastructure. Checked all extra managed functions of the TP-Link TL-SG108E Smart Switch that we used, containing Storm Control (What already was disabled) and disabled everything not needed. Even changed it to an unmanaged small business switch.

It didn't change anything! At least this would be a bit strange, as the production computer itself is in the same network, and working fine as long as one doesn't switch between the production software control and the direct control via tcp script and back.