WATCHOUT, WATCHNET and Autostart.txt

[Andreas Lindemark]

Hi,

 

I'm not sure how to use Autostart.txt when running WATCHOUT on two (or more computers) in the same cluster and I also run WATCHNET on a separate computer. I'm currently running WO 6.0.2 and WN 1.1.

 

Should I have the same autostart.txt in the all WATCHOUT computers in the same cluster?

authenticate 1
setLogoString "The show will begin shortly..."
delay 5000
load "MyShow"
wait
run

I'm only using "setLogoString" to show that the autostart.txt is loaded and used.

 

The reason I'm asking, is that I sometime have problem to get WATCHNET to work, I guess it's depending on in which order I start the computers. And I haven't found any information in the forum, when it comes to running on several computers.

 

Any help is appreciated!

 

 

[jfk]

Hi,

 

I'm not sure how to use Autostart.txt when running WATCHOUT on two (or more computers) in the same cluster and I also run WATCHNET on a separate computer. I'm currently running WO 6.0.2 and WN 1.1.

 

Should I have the same autostart.txt in the all WATCHOUT computers in the same cluster?

...

 

No! Definitely not. If you do, the system will act very strangely.

(I have had customers do this, and it will cause all kinds of problems.)

 

You only need to run the script on one computer.

Any one computer will do, they all contain the needed information to manage the other members of the cluster.

[Hugo Janzen]

Hi,

 

I've a situation which might be related to your post:

 

- 3 Display PC's WO5

- WNet 1.0

 

Running a timeline started by WN with movies "free running" & "Looping", will only run & loop on the DIsplay PC which is Primary in the cluster.

On the other two Display PC's the movies will flash and freeze.

 

Changing the Primary Cluster to an other Display PC will have that PC run fine and the other two will behave as described.

 

The Load Show is executed by WN and not by a script Cmd.txt as autostart.

 

Hugo

[jfk]

Hi,

 

I've a situation which might be related to your post:

 

- 3 Display PC's WO5

- WNet 1.0

 

Running a timeline started by WN with movies "free running" & "Looping", will only run & loop on the DIsplay PC which is Primary in the cluster.

On the other two Display PC's the movies will flash and freeze.

 

Changing the Primary Cluster to an other Display PC will have that PC run fine and the other two will behave as described.

 

The Load Show is executed by WN and not by a script Cmd.txt as autostart.

 

Hugo

 

When do watchpoint cluster members flash and freeze -

at the start of each cue run?

immediately upon ecnountering the free running / looping movie cue?

or after the completion of the first pass, failing to loop?

 

I would take a close look to see if network is blocking UDP multicast packets

from the watchpoint cluster master to the watchpoint cluster members.

I see this occur in managed networks, where

UDP flood / UDP storm protection against DOS attacks

also blocks the watchpoint cluster master UDP multicast.

Keep in mind, WATCHPOINT sends transport commands to the master,

then the master relays them to the members via UDP multi-cast (mostly).

There are times when a command is sent from the master to the members via TCP/IP,

pretty sure show load is done TCP/IP, but mostly it is done via UDP.

[Steve Farris]

I have noticed an anomaly in cluster mode which might apply.  I have a timeline that starts some looping videos, then pauses and waits for external commands from a midi keyboard (I am not using Watchnet).  When I start up the cluster, the primary functions as it should.  However, if the slaves start such that they enter Watchpoint after the primary has hit the pause, the displays will load and jump to the pause (since that is where the master is), but the loops never start.  In other words, on the slaves the display is a still frame of the video at the point where the pause sits on the timeline.  Once I send external commands that cause the displays to move around, the slaves behave as they should.

 

Since this is related to startup order and what kind of commands the slaves receive from the master, perhaps there might be a similar issue?

[jfk]

I have noticed an anomaly in cluster mode which might apply.  I have a timeline that starts some looping videos, then pauses and waits for external commands from a midi keyboard (I am not using Watchnet).  When I start up the cluster, the primary functions as it should.  However, if the slaves start such that they enter Watchpoint after the primary has hit the pause, the displays will load and jump to the pause (since that is where the master is), but the loops never start.  In other words, on the slaves the display is a still frame of the video at the point where the pause sits on the timeline.  Once I send external commands that cause the displays to move around, the slaves behave as they should.

 

Since this is related to startup order and what kind of commands the slaves receive from the master, perhaps there might be a similar issue?

 

I do not think so.

 

That sounds more like an issue with the timing of the first cue when the aux timeline comes out of STOP and transitions to RUN.

It is normal for cues in the first few tenths of the timeline to be skipped during this transition.

so what you describe is what would be expected if that aux timeline looping cue is at time 0.0

Once the timeline is in run or pause (halt), i.e. not stop,

that issue will not repeat, as you describe, as the transition from stop has already occurred.

[Andreas Lindemark]

Thanks, for all replies!

 

I have changed my configurations (only one of the Display computers load the show).

 

Now I will wait and see if it works better, and if the users of the system still complain about this issue.

[Steve Farris]

It is normal for cues in the first few tenths of the timeline to be skipped during this transition.

so what you describe is what would be expected if that aux timeline looping cue is at time 0.0

Once the timeline is in run or pause (halt), i.e. not stop,

that issue will not repeat, as you describe, as the transition from stop has already occurred.

 

 

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.

[jfk]

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.

[Steve Farris]

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.

 

Interesting. I am indeed using an autostart script on the master computer.  The slave computer just launches Watchpoint and then waits.   If I understand you correctly, the master computer should be sending out UDP broadcasts that will tell the slave computer to play the videos that are looping, even if the "timeline" is paused before the slave has loaded the show.

 

I am using a basic, unmanaged Netgear GS116 switch (http://www.netgear.com/business/products/switches/unmanaged/GS116.aspx#tab-techspecs).  When I look at the specs, I don't see where it is distinguishing between types of packets.  The computers are running Win7 Home and tweaked according to the Win7 guidelines for Watchout.  Is there a windows setting that would stop UDP broadcasts?

 

I was assuming the issue was that the master display is paused with a looping video, and since the slave display loads the show in this state, the looping video doesn't play since it jumps to the location through a "goto" command rather than a "play" command.

[jfk]

Interesting. I am indeed using an autostart script on the master computer.  The slave computer just launches Watchpoint and then waits.   If I understand you correctly, the master computer should be sending out UDP broadcasts that will tell the slave computer to play the videos that are looping, even if the "timeline" is paused before the slave has loaded the show.

 

*No*

 

I am using a basic, unmanaged Netgear GS116 switch (http://www.netgear.com/business/products/switches/unmanaged/GS116.aspx#tab-techspecs).  When I look at the specs, I don't see where it is distinguishing between types of packets.  The computers are running Win7 Home and tweaked according to the Win7 guidelines for Watchout.  Is there a windows setting that would stop UDP broadcasts?

 

I was assuming the issue was that the master display is paused with a looping video, and since the slave display loads the show in this state, the looping video doesn't play since it jumps to the location through a "goto" command rather than a "play" command.

Looping will synch up, looping and free running will not.