jfk

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.