Jump to content
Dataton Forum
scott britt

SMPTE occasional SYNC issue with WO Version 5.5.1

Recommended Posts

So we have used Watchout since version 3...and have now had a problem show up several times during shows that I need assistance with...


A little background...The systems are Watchout systems on Windows 7 - 64 bit...running 5.5.1...on SSD drives with extreme I7 processors...the problem has been now seen with two completely different systems...with two different show files...


All of our shows are locked to a master SMPTE (LTC) timecode source that is fed into WATCHOUT via a AudioFire Pre8...both systems do have the same hardware...Asus Sabretooth motherboards, etc...


Occasionally, perhaps 3 times out of 70 shows...the Watchout playback would start out "sync'd" and quickly get out of sync with all other SMPTE devices tracking timecode...this out of sync actually worstens as you get further from the start point...as much as 1.5 seconds off by the end of a 30 minute show has been noticed...


Upon checking further...we tried simply stopping Watchout and re-starting Watchout...same result...it is reproduceable within the boot session...


A Reset of the computer WILL fix the problem...and all is good...until the next in-opportune time that it decides to do this...Rebooting a 4-projector fed Watchout display computer in a show environment is not something anyone really wants to consider...while rolling...


These same machines ran version 5.2 last year and never saw these issues...now I have seen this at least 3-4 times...I'm going to have to start running several minutes of show ever night on bootup to make sure that sync maintains...this SHOULD NOT be necessary...


I hope someone can shed some light or at least acknowledge this problem...I feel like I never know when something will not be sync'd right...and since the Watchout system is also providing the audio playback for the show...it is serious if it is out of sync!


Thanks in advance for your time!

Scott Britt

Interlaced Productions

Share this post

Link to post
Share on other sites

This may  be caused by using the "Auto Detect" setting for timecode type.

In auto detect, each time the timecode signal appears,

WATCHOUT analyses the timecode and determines the timecode type.

If it gets that wrong, then what you describe will occur.

I have seen this occur with less than ideal audio signal levels (usually to hot).


Simple solution is to set the timecode type explicitly.

An added benefit of explicit timecode type setting is faster lockup to timecode,

as the system then skips the analysis process.

Share this post

Link to post
Share on other sites

I am setting the timecode type in the "CMD.TXT" file:


authenticate 1

timecodemode 5

load "xxxxx"



The protocol commands are extremely case sensitive, there is no variation accepted.

I trust that is not exactly as it is used, as there is an error in that timecodeMode command.


5 = SMPTE 30 (”B&W”) which is fairly uncommon.

If the TC is in fact 29.97, which is far more common, then that would explain the drift.


Also, SMPTE 30 (”B&W”) can not be auto detected, for that type of timecode to work correctly,

it must be set explicitly. So if your case is wrong in your command file, fix that first.

Share this post

Link to post
Share on other sites

Thanks but that is not the issue...we ran this system with same settings last year...this is one of the rack mount computers from Showsage...


and now we have seen it with another older Watchout system that just got upgraded to the new software...


The case is correct on the text...I just typed it quickly...

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now