RBeddig

Free run and loop does exactly what it says. Free run means FREE RUN, i.e. WATCHOUT releases control over the file and does not care about keeping in sync anymore. You can loop using cue points but you should make sure that the loop cue sits a few fractions of a second inside the video cue - before it get's unloaded from the graphic cards memory - and you jump back into the first frame, not before the first frame! It can be helpful to have the same frame twice at the beginning and the end of the video.

We have actually not seen this behavior although we have done similar things in our recent projects. To make it easier for the support team to help here, pls. elaborate a bit which Windows version you're using, the codec specs of your video and whether this happens using the main timeline or an auxiliary timeline.

If you do not close the command with \r, WATCHOUT will ignore it until the incoming buffer is full. BTW, the gotoTime command would look like this: gotoTime "00:00:01.000" timeline or gotoTime 1000 timeline if the name of the aux timeline is timeline.

The CR (\r) is important since this will tell WATCHOUT that the command is complete and can be analyzed. TCP/IP has the benefit that the sender will get a receipt. UDP just sends but does not care whether the receiver is listening. If you have trouble making unity3D talk to WATCHOUT, try a telnet client like PUTTY and send RAW messages to WATCHOUT. You'll see all responses and it's easier to troubleshoot problems. Once you've figured out what to send you can go to your application and build it from there.

Actually we do this at times when transferring very large files to display computers. In this case we usually transfer one file first since this will build the correct structure in the show folder on the display computer. Then we connect an external SSD to the display computer and copy the rest of the files directly into this folder. This doesn't work that easy with locked systems like WATCHPAX or WATCHMAX but open systems should accept this. Once all the files are on the display server, you connect the SSD to your production computer so that WATCHMAKER also sees the files. On going online WATCHMAKER will just compare the files with those on the server.

Are you sending a CR at the end of your control command? x0D? Have you tried using TCP/IP?

What jumps into my eye are these time stamps. { "date" : "2019-01-25", "time" : "3:04:35:186", "severity" : "error", "error" : { "kind" : "Network", "code" : 0, "excuse" : "Display computer: Disappeared", "source" : "Display \"Display 2\" of Stage Tier \"Base\" of Stage" } }, { "date" : "2019-01-26", "time" : "3:04:35:450", "severity" : "error", "error" : { "kind" : "Network", "code" : 0, "excuse" : "Display computer: Disappeared", "source" : "Display \"Display 2\" of Stage Tier \"Base\" of Stage" } }, { "date" : "2019-01-27", "time" : "3:04:39:981", "severity" : "error", "error" : { "kind" : "Network", "code" : 0, "excuse" : "Display computer: Disappeared", "source" : "Display \"Display 2\" of Stage Tier \"Base\" of Stage" } }, { "date" : "2019-01-28", "time" : "3:04:39:896", "severity" : "error", "error" : { "kind" : "Network", "code" : 0, "excuse" : "Display computer: Disappeared", "source" : "Display \"Display 2\" of Stage Tier \"Base\" of Stage" } }, What is happening in your installation at 03:04 every day. Are you shutting the computer down at this time? If not, I would investigate the Windows scheduler. There are numerous things happening in a computer in regular intervals and if errors happen at the same time every day it might be something triggered by the scheduler.

I think the app only makes use of the camera while meaman wanted to show the iOS and some iOS app. So what he would need is to mirror his screen.

You do not need to install the vidvox HAP codec. WATCHOUT uses it's own codec and this is integrated in WATCHOUT. Installing the HAP codec might only make sense on a production computer in case that you want to use QT based software to transcode media. WATCHOUT does not need it. If I understand your description correctly, you are playing more than one video back-to-back in a timeline and then, after a couple of videos, you want to transition back to the beginning at 0:00.00? Using a control cue to jump back to the beginning will only work if you place one control cue appr. 1/2 frame inside the video at the beginning and a second control cue 1/2 frame before the end which points to the name of the first control cue. How much you have to stay away from the video edges depends a bit on the power of your system. Here ideally you have a looping video where the last frame is identical to the first frame. The reason is that once the timeline has reached the real end of your video the graphic card will kick it out. When you now jump back to 0.0 and your video starts here as well, WATCHOUT will have to load the video again without any chance to do this before showing the first frame. Usually WATCHOUT reads the video slightly before it gets rendered. Note that this way of looping only works when you play one clip only and you should normally avoid this approach. The normal way of playing loops would be to set the video in free-running and looping mode and stop at a pause cue. If you do this with one clip it should not show black. In this case WATCHOUT will load a second instance of the file to do the looping transition. This also means that your hardware needs to be able to play two instances of the file at the same time! If you have more than one video in a row and want to play the complete part in a loop, you'd need to first build your show in a timeline and then copy it to a composition. Make sure that the length of the composition is exactly as long as the videos! All videos inside your composition should not be set to free-running and looping. Instead you'd put the composition in free-running and looping mode. There are thousands of reasons why a computer or software might crash and no software can find all the reasons why it might crash. This is one of the main reasons why Dataton started to build WATCHMAX and WATCHPAX servers since here the dev team can do long time test runs and tweak Windows and all drivers to make the system stable and fast. Changing the version of a single driver can dramatically change the behavior of a software. But there is some help. WATCHOUT writes a couple of log files, both on the production computer and on the display computer. They are placed inside the folder logs in the WATCHOUT folder. Read those files and possibly this might get you a hint. Windows also writes log files of the Windows system. >> Control Panel/Administrative Tools/Event Viewer/Windows Logs It is also a good idea to double check the tweaking of your system. I've seen crashes where the owner of the system swore that it was fully tweaked and in the end it was a tiny settings which he overlooked which caused the crashes. BTW, when posting here it always helps to mention the version of WATCHOUT 😉

If it can be connected to a cable, you could use an adaptor to HDMI. AppleTV should also support mirroring mode and has a HDMI output. The HDMI signal can then be used through a HDMI capture card or by converting it to NDI.

Why would you use a proxy anyway? It's in the nature of a proxy that WATCHOUT does not really analyze the file and therefore can't see how many channels are used.

The S400 sync board is an extension to the W/WX series of graphic cards and intended to framelock physical outputs on those graphic cards. What the MST hub does when it gets a signal from the graphic card is outside of the control of the S400 sync board.

The hardware looks powerful enough and we have a few MSI gaming notebooks with Win 8.1 for WATCHOUT programming. How fast is your disc? Which graphic card is used with WATCHOUT? What falls into my eye from your long spec list is: Why do you have virtualization active? Resolution 1920 x 1080 x 120 hertz Is your display running on 120Hz??? This could indeed be a problem since WATCHOUT would need to render everything in real time to 120Hz.

It looks like a network issue. Make sure that you've turned off all network ports except the one which you use for WATCHOUT. Otherwise TCP commands and UDP commands might use different paths and this would look like your description. It is also a good idea to get rid of any bloatware installed on your computer. Those can lead to astonishing effects.

Indeed, this points more to a network issue I guess. Free-running means free-running, so WATCHOUT will not keep track of the files after starting them.

Hi, It looks more like a hardware/driver or network issue. I've just tested three UHD clips with 50 and z60fps on a WX7100 set to UHD@60fps. Though the clips have the same content, it's actually three individual files each. The server runs Win7 Pro 64 and the AMD driver is from Q4/2017. We had severe issues with drivers from Q1/2018 but have not tested any from this year yet. UHD@59.94p-HAPQ.MOV UHD@50p-MP4.MOV

Basically Alex is right but those notebooks usually have plenty of bloatware installed and the first thing to do should be cleaning the disc and reinstalling a clean Windows.

If the number of displays in your project and the resolution is a problem in 6.4.1, a hint for a workaround could be this: You can select all the displays in your show except one and copy/paste them into a text file (unformatted text format of a simple editor, not RTF, DOCX,...). Then you can delete those from your show. Once the transfer is done, mark all the text in your text file and copy/paste it back into the stage window. This would reduce the number of displays temporarily and might help to speed things up.

The formula works fine on my system with WATCHOUT 6.4.12 and should do the same with 6.2.2. I would not use a value of 100 though and divide it by 100 again, I would just use a limit of 1 and just type the variable name or even "TweenValue * Volume" into the edit field. We are using float values which should be accurate enough even when the limit is on 1. What do you see next to the green "F" when you send data and have the tween channel activated (open) so that you can monitor it? Greetings from Berlin :-)

While Jim is, as always, is explaining a valid way to solve your issue, the "standby" state might be an issue to think of too. If you just toggle between normla state and standby state, the timeline usually does not run and can not trigger any cues to control WATCHOUT. So you need to start the timeline containing the stills as well to make the cue work. Of course an internal loop point to jump back just before those cues would work and of course, one cue needs to be in a standby layer too. If you do not control any lights through ArtNet / DMX, you could also use DMX as a sort of variable. In this case I would use two variables since DMX cues increase to a certain value and not jump. You can set the IN and OUT universes to the same number and can use DMX out cues to control DMX in cues. The benefit would be that you do not have to care about loosing the authentication.

Dataton offers a XEON-based production notebook. Ask your Premium Partner about this offering.

The benefit of using 3D object files with a uv mesh is that WATCHOUT then knows the orientation in 3D space AND the pixel flow around the object. What you're describing is the "old fashioned" approach to "3D mapping" (I would call this 2D mapping), taking a picture from the projection point and then animating each projector view separately. The logical result is that your content would only work for a given projector position incl. the correct lens factor, projector orientation,... If you move the projector slightly to another position, you're out. Unfortunately I do not see a way to use the easy 6-point calibration for your workflow. And sorry, there is no documentation from Dataton for your workflow.

Using two NICs on a production computer is calling for trouble. WATCHOUT will not listen on both networks and furthermore it is likely to happen that e.g. TCP/IP commands go through one NIC while UDP takes the other. This will lead to an error described here before, i.e. you can position your timeline but when you want to roll it, it will not roll.

Have you tested driver version 2017Q4.1 yet? I've just received some information that 2019Q2 has a known bug which can lead to tearing within a display group even if you use the S400 sync board. This is planned to be fixed in the next update in 2-3 weeks. Don't know though what they might break in the update on other aspects.

I'm not sure but this older model from Datapath was initially produced to capture computer signals, not really camera signals. Cameras often use different colour spaces etc.