Mike Fahl

Well, that's really for Dataton to answer, but unless things have changed since I made it (which I doubt), file transfers and general commands use TCP while play/pause, time synchronization, variables, etc use UDP multicast. Note that the port used for the multicast is dynamically chosen, so there's no known fixed port here. The same goes for the multicast address, which will be from the "administratively scoped" range (all this from memory, and with the above caveat). Mike

Well, technically play/sync messages are multicast, so they may work across networks, assuming IGMP is configured on routers to allow for this. But in general, as Jim says, this is to be avoided unless you have a very good grip on your network infrastructure an its configuration. Mike

I'm so sorry to hear. Mark was such a gentle and nice person. My condoleances. Mike

The container format usually doesn't matter. Both MOV and MP4 are container formats. However, MOV is a superset of MP4 (i.e., MP4 is based on the MOV file format, originally developed by Apple). An MP4 file is essentially a MOV file with some restrictions and (typically) containing H.264 video and possibly AAC audio. So if you have a MOV file containing video/audio with those codecs, it is essentially an MP4 file. More on these and other container formats here: https://www.quora.com/What-is-the-difference-between-video-file-types-e-g-mp4-mov-avi Mike

The data received back by this subscription mechanism provides a very accurate time position. The Status message carries three parameters: The name of the timeline. The run mode, where 1 is paused and 2 is playing. The current time position, in mS. WO will notify you whenever there's an abrupt change. Based on those updates, you can extrapolate the current time position at any instant. Mike

At some point there was a feature that sent a messag if you named a Control cue with a leading colon (if memory serves me correctly). At least the display software did that, to its primary controller. Perhaps that "hack" is still in there? Worth giving a try. Test it with a telnet client to see if you get something back when running over such a control cue. Mike

For 1, I would not use polling for that. Use the subscription model intead. WO will then tell you when there's any abrupt change. Interpolate/extrapolate intermediate values based on the data you get. For 2, just give it a try. If it works then you should be good to go. Mike

You can send commands and receive error messages related to those commands through the same network (TCP) connection. This is described in the manual. What do you mean by "receive notifications from WatchOut Outputs"? Mike

If you use the subscription model, there's no need to repeat the command. Whilw the subscription is active, WO will tell you whenever there's a change, without you having to poll it constantly. That's the whole idea. The additional parameter follwing "getStatus n" (where n is 0 for start subscription and 1 to end subscription, if memory serves me correctly) is the path to the auxiliary timeline to subscribe to. Without this parameter, main timeline is targeted. Mike

Remember to quote the target cue name if it contains spaces or other odd characters, Easies is to always quote strings. Mike

If you have multiple NICs on your computer, you may need to set the priority order of NICs in Windows so the one used by Artnet is at the top. If not, WO may send Artnet data on the wrong NIC. Mike

Since this happens only after a full restart, and once the system is up and stable does not happen again until the system is restarted, my guess is on some other program, driver or similar running in the background on the display computer. That "other" thing does something that kicks WATCHOUT out of full screen mode after a several minutes. If the problem were caused by some video codec bug, it should manifest even after running successfully ones, since what then happens is pretty much the same on every run of the show. Of course, the tricky part is finding out what that "other" thing is. Especially since it happens so rarely. Mike

Why would it matter if it gets the command twice? They should both say the same thing pretty much at the samr time anyway, shouldn't they? Mike

I see there's a "UDP/TCP Generic module" as well for Companion. Assuming this module can receive data (to trigger commands or "stacks" in Companion) you should be able to use that one, as WO can send TCP and UDP command strings quite easily. Mike

If prod sw and WN runs on the same PC, you should be able to just put localhost into the address field. If they're on separate PCs, put the IP address of the WO prod PC in this field.