jfk

Keep in mind that when in standby the non-standby content is still rendered on display, even though you do not see it. So it could well be related to the movie encoding of the movies you are scrubbing. mpeg with B frames is particularly known to cause this issue. Try scrubbing the same movies when not in standby, same issue should occur.

Shot in the dark, but I have seen this happen when user installed VNC is added to the WATCHOUT computer. Uninstalling did not help. The only way to get rid of the issue was to completely restore the original pristine tuned state.

Increasing the start delay to such a large number likely just results in an error and no delay (check the error log on the display computer). Yes, scheduling defray at startup could definitely be the cause. Simple enough to disable it and try again.

When you see the task bar on WATCHOUT Display full screen mode after power up and autostart of Watchpoint 6.5, it likely means that WATCHOUT has loaded before Windows has completed starting up. Increase your start delay to avoid this.

Your manufacturer's utility uses their own proprietary driver. WATCHOUT uses a generic Microsoft Windows Driver Model (WDM) driver the should be supplied by the same manufactuer. So the manufacturer's utility verifies the signal is connected properly, it does not verify the WDM driver is functioning properly. You might want to contact your vendor or check message boards related to that product to determine if there is a known WDM issue.

x2

Then I suspect your EDID management has changed / malfunctioned, as you are now seeing what would be expected if there were no EDID management.

... and Nigel provided instructions on how to do it from the production computer. The existing method is very flexible. At that point, it is a matter of opinion I guess, as Nigel states "It's really easy to do ..."

The big issue is you indicate it has worked for two years. Clearly something has changed in the hardware or OS configuration. Quite honestly, I am surprised it ever worked as described — running computers 24/7 while turning on and off displays every day. Unless you are running EDID management, just a really bad idea. I would expect loops to stop and other issues when you force a graphics card reset by disrupting the display connection while the show is running. Sounds normal to me. Best practice is to power down display computers first / before powering down displays last. And then power up displays first and power up computers last. Running computers when nothing is being displayed is wasteful of energy and destabilizes the computer. But as you indicated, it worked for two years for you. As such, pretty much leaves you on your own when you have had success with less than best practice. And now you are seeing what we would expect all along, so how does anyone address that? "i ran computer check for the graphic card, cpu, memory, disc"

To remove the default edge blending, best way is to disable blending in each output definition. Display Settings - Advanced - Uncheck Use Default Soft Edges If you have defined custom masks, that would be different.

If you are only using it for editing and don’t mind an occasional crash from Windows background activity, then home is acceptable. That works ok for integrators, etc who run their actual playback in cluster mode (without production). If you choose to run the actual playback live from production, home is not such a good idea.

Bad idea. The removed USB License will take approximately two to five minutes before its absence will force production offline. At that point, the system loses its timing master. (i.e. Dataton provides a grace period if a key is momentarily removed). As Callum correctly suggests, moving the timing master to a display computer by invoking cluster mode will allow playback without production. Just remember, if the show is already loaded by production, you must still send a valid load command from IP. load is the only command that moves the timing master. It establishes the display computer executing the load as the new cluster master. If you do not do this after an online production session, IP cluster commands will not be relayed to the other display computers in the system among other potential anomalies.

In addition to production error window messages, look in the Watchout folder for a logs folder in the computer that actually crashes. In there will be plain text files with event records that may more accurately identify the issue.

If the fan does not rev up to full speed on power up (and then step down), arrange repair with your Premium Partner or go to https://www.dataton.com/rma-application-form

There are two types of NDI streams - NDI (which is essentially uncompressed, for example 1920×1080@30 fps NDI stream ≈ 125 Mbps) and NDI | HX (aka high efficiency - which is h.264 compressed, 1920×1080@30 fps NDI | HX stream is from 8 to 20 Mbps). Sounds like you may be using NDI | HX. Long delays in acquiring an NDI | HX stream are normal due to the compression used in that stream type.

Simple answer is no. There is an undocumented experimental cluster control command that allows interactive adjustment of playback speed. It would require a control system to achieve any useful function. This adjustment effects all playback (i.e. the timeline speed is adjusted, not just an individual piece of media's playback speed). The experimental function is limited to ±20%, which may not be able to achieve what you describe. And keep in mind, this function is cluster mode only, it is not available when watchmaker is online.

This appears to be some kind of hardware issue. We have not seen any other reports of this nature. If you would like to have Dataton evaluate this, please send a simplified sample show file, media and description of how to reproduce the issue to support@dataton.com. We would test it on our hardware to see if it is reproducible. The loop setting solving the issue is very strange. It is exactly the opposite of what we would normally observe. Looping loads a second copy of the media which increases the work load - often movies that play ok standalone begin to stumble when looping is enabled. Again this points to some sort of very unusual hardware anomaly.

You might be surprised how often that has come up. Two matched audio sources many times appears as an echo or reverb effect. Glad you got it sorted. Very much appreciated that your reported back with the resolution.

File transfer communication between watchmaker and watchpoint is TCP. No file sharing OS services are used and should be disabled. Since its the two watchout family software packages talking to each other, i suspect the protocol is irrelevant.

Are you sure the original is not a HAP Q Alpha? (an unsupported codec in WATCHOUT)

Essentially correct. It would be more correct to say ... watchout can only output 8 bits and no more ,unfortunately... i.e. In some cases it can play movies with higher bit depths, but those will be reduced to 8 bit for output.

ectoplasmosis, your statement could be misleading. I assume the SFP+ qualifier is how you arrive at the statement "No 10Gb SFP+ NICs that support WoL ..." MS was looking for a PCIe interface and he indicates he is aware of a 10 Gb NIC compatible with Wake On LAN that is experiencing long delivery times, just looking for alternatives that are more readily available. BTW, the WATCHPAX 60 includes a 10 Gb NIC that provides Wake On LAN function.

No. It is important that the network interface used by WATCHOUT be the highest priority in the NIC priority Widows settings. So no, you can not set it in WATCHOUT, but yes, you can set it in Windows.

I do not know how your control product sends its strings. All commands to WATCHOUT must have a carriage return at the end of the command. When typing a command from telnet, this is accomplished by hitting the return key. Control products use various methods of sending the carriage return at the end of the command string. Some use /r. Some send the the two digits representing the single byte hex value with some hexadecimal value indicator, , I have seen 0Dh, etc - for example, WATCHOUT itself uses a dollar sign ($) to indicate the next two digits are a single byte hex value, so in a WATCHOUT output cue, you would type $0D to send a carriage return. The method used to define hexadecimal bytes is determined by your control product.

Yes, change the output device port number to 3040 for use with production and you can skip the authenticate command. Also, be sure to enable IP control in File - Preferences - Control.