RBeddig

If the server is not connected to a network, then I can confirm Mike's guess. We've solved this by using a simple network loopback plug. You can easily build it for yourself or by it for a $, € or whatever.

Virtual displays are more like intermediate layers, which are usually used for LED pixel mapping or as a content canvas for 3D mapping. WATCHOUT 6.x does not support NDI out.

What are your computer specs, how fast is your SSD drive, how many outputs are you using in which resolution, which version of WATCHOUT are you using and how large (px) are your files? I've played HAP files back-to-back without any issues for years and have only seen black frames when either the video file had an unintentional black frame or when trying to loop a file through control cues sitting outside the video cue rectangle.

You could try to give it some additional pre-roll so that the loading of the file starts a bit earlier.

A quick google search showed this: https://www.hresult.info/FACILITY_ITF/0x00040242 DirectShow: Some of the streams in this movie are in an unsupported format. If DirectShow can't decode the file, WATCHOUT can't play it.

Are you using the audio outputs of the servers and if yes, how many? Can you disable those for a test? rthdasio.dll seems to be the Realtek asio driver.

There can be hundreds of reasons why a server doesn't run stable or perform well. One of the reasons why WATCHPAX servers seem to be more expensive than self-built servers is the fact that the development of a stable system consumes months of manpower for testing and fine tuning. The best starting point to check for issues are still log files. Windows log files and WATCHOUT log files. If you're not ready to check those I guess nobody will be able to help here. Of course it can also be related to hardware and drivers. I've seen servers rebooting completely after 6-10 hours without any visible reason and without an entry in a log file. The reason back then was that the RAM modules, which were in fact specified in the QVL, were not compatible to each other. One RAM module worked but as soon as I ha d more than one in the server, it would crash after hours.

Hmmm, If you know the IP number and port of the device to control and the protocol, there is not much to add to the manual. Create a string output, set this to TCP/IP or UDP - most people don't have COM ports anymore on their computers - and drag the new entry from the output window into the timeline. Give it any name and type the correct command into the big empty space. The problem in the communication is usually the receiver. Some devices react when you just send the string, others need a delimiter at the end like carriage return ($0D) or maybe even a start byte. Some devices want TCP/IP, others can live with UDP (no receipt for received strings). My approach is usually to use something like PuTTY on the production computer and then try out the strings which you'll hopefully find in the device documentation of the third-party device to be controlled. Once you've learned which commands work with your device, you can copy those strings into the cues and fire them off in your timeline.

Have you check the log files of WATCHOUT or the logged events of Windows for a clue?

And here is the missing link.... Dataton Serial Smartlinks.pdf

Hi Jon, Don't you have anyone who can solder the cables for you? They seem to be pretty straight forward and don't have any active components inside. To make it fit to the locked output of the SMARTPAX, I'd just use the actual subD plug without the cover or, if you can still get hold of something like this, we sometimes used very simple molded RS232 extender cables and just cut the wrong side off. /Rainer

Not to my knowledge. Have you tried to use some simple telnet commands to simulate the commands of the script? I'd start using something like PuTTY to send the commands one by one. This also give you some feedback from WATCHOUT which might help to trace down the issue.

I usually keep away from auto-save as well. It's a feature for people who tend to forget to save from time to time while programming. I usually "save a copy as..." to a file myShow_date_time.watch when I think that it is a good time for making a snapshot of my work. Saving in set intervals might just save things which I actually want to get rid of and when reverting to such a snapshot I might not find it very useful. And don't forget to prepare a consolidated show once your ready or at the end of your working day preparing a live show.

Difficult to say without knowing anything about how you build your project and how you prepared your content. Looks as if you just project a standard grid onto a half-sphere. Is it 3D projection mapping with a 3D model and correct uv mesh? Are you using a calibration system? ...

If it's rather static, you could also give the "Computer Screen" media a try. It's basically VNC and will probably give you not more than 12-15fps.

Well, you should be aware of the bandwidth of NDI signals. https://support.newtek.com/hc/en-us/articles/217662708-NDI-Network-Bandwidth In NDI networks, senders and receivers need to be counted. I.e. 8 senders sending 1080p60 to 8 receivers will need around 2.000-2.500 Mbps bandwidth in your network. If you go down to NDI-HX (more latency, higher compression), you'll cut this roughly by 1/10th.

Hi Mikael, may I suggest to add this to the autostart.txt on the WATCHPAX units? Until now, it only included the network mask but not the extra parameters. Thanks, Rainer

No, there is no show project to download. Check the tutorial videos here: https://www.dataton.com/training/academy-training-videos and here: https://vimeo.com/channels/watchout Skip the 3D videos for now since they might be confusing when you just start exploring WATCHOUT.

Maybe you should be a bit more specific. When talking about a Blackmagic device, I would assume that you're talking about a capture card which takes your source signal (e.g. HDMI) and feeds this into the computer over PCIs slots or USB? You're talking about We stopped using Blackmagic devices quite some years ago due to the total lack of support and the quality of their drivers. Therefore I actually can't say whether there is a Blackmagic NDI encoder/decoder on the market or not. NDI is a signal traveling through the network, usually encoded by some hardware encoder but sometimes also encoded by the source device itself. Trying to use video signals coming into physical inputs of a capture card and signals using NDI encoding will most probably end up in a lack of synchronization. Encoding and decoding video signals to/from NDI usually leads to appr. 1 frame delay since the encoder has to analyze, compress and repack the incoming stream into the NDI format. When we measured the difference between signals going directly into a Datapath capture card and those from the same source going through a fast NDI converter into WATCHOUT, we measured 1 frame difference. On other servers with different capture cards we even saw that the NDI signal was a frame faster than the captured signal. If the signal needs to be changed in the frame rate or resolution, the delay can even be noticeably longer. If you compare, you should use the same frame rate and resolution on the source side and in WATCHOUT. Then you can measure whether the capture card is faster (which is probably the case) and how much faster it is. Adding frame rate conversions or scaling will usually lead to more latency and this will be different on a capture card or the NDI encoding process.

Sounds a bit like the network issue discussed in several posts in the forum already. Are you sure that you only have ONE open network connection on your production computer? When you played with NDI, did you change anything in respect to broadcast (UDP) messages on the network?

Might be that the WX8200 is not supported in the 17Q4 driver. If you want to give it a try you can contact me for a download link to my server. WATCHOUT uses different decoders than the Media Player which can lead to different quality. To really analyse the problem opening a ticket at the support page might help.

I just checked that we had something similar on a project with LTC @ 30fps and WATCHOUT 6.4. In this version, all incoming timecode was interpreted as 25fps and WATCHOUT was appr. 4 sec. ahead of the timecode while the timecode tester app in the WATCHOUT folder was accurate. This behavior was fixed in 6.4.1 and versions before 6.4 were not affected either.

There was also a bug in an earlier version of WATCHOUT 6 (don't remember which one right now) where the incoming timecode and the WATCHOUT timeline position could be off by a few seconds with NTSC timecode. This was resolved shortly after so make sure that your WATCHOUT version is quite up-to-date.

Windows uses two different modes to drive a graphic card. So does WATCHOUT. Before WATCHOUT goes online, the display computer is in the GDI mode of the graphic card and to my understanding, the GDI mode is controlled by the Windows settings. When WATCHOUT switches to the online mode, it also switches to use the Direct3D mode of Windows to increase performance. In this mode you do not see any windows, menu bars,... and many computer games use this mode too when they run in full screen mode. I guess that the Lightware fiber transmitter uses the wrong EDID information. Being a fiber transmitter, you probably have to teach the transmitter the correct EDID for the needed resolution and frame rate. If you just copy the complete EDID set from your projector, your graphic card is sort of free to negotiate a resolution while the graphic card will try to use the preferred resolution of the display. The solution would be to teach your transmitter only the resolution it should use in online mode. This would force the graphic card to always use this resolution. Since you're using NVidea you should also read the posting

I'll check next week when I'm back at the office. You can send me a private email with your contact details so that we can take it off forum. Actually you can find my contact on the Dataton website as the German Premium Partner.