RBeddig

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.

Doubt that there is a fix needed since sending TCP/IP and UDP works fine from WATCHOUT. If it doesn't work for you, you should check whether the computer blocks something or whether there is an issue in the network or with your strings. Having programmed show control systems for the last 30 years, my first functionality test starts with a program like PUTTY. It merely does the same what WATCHOUT would do but it is easier to find problems in the first place. If PUTTY does not work, check what's blocking the port!

Cooling of the media drive could be an issue. When M.2 SSD get hot they throttle down. Also check whether you have turned off everything that is related to throttling down the cpu when the load is low. SpeedStep etc. HAP does not give much load and the computer might feel that it is in idle mode. You can test this by adding a H.264 in the background. This will keep the cpu more busy and the computer will not step down.

I'm not a friend of consumer cards since they are usually outdated within weeks again and if something breaks you'll never be able to get the same graphic card again, but... The speed of the graphic cards is not the main factor for WATCHOUT anyway. Except for HAP codecs, the rendering is done on the CPU and the GPU is not used that much. On the other hand Tweens are handled by the GPU rather than the CPU. So if you mainly plan to play videos as they are you won't need the fastest GPU.

The MP4 (H.264) format does not hold any information on transparency. Transcoding this to another format will not generate the extra byte needed for the transparency.

MP4 (H.264) uses temporal and spatial compression and depending on the settings in the encoder can be compressed quite a lot. The back draw of this is that the CPU needs to buffer a lot of frames - even more if you compress B-frames as well - to recalculate the individual frames in real time. I've seen a 4K video compressed to less than 1 Mbit/s which then played back with 1-2 fps on a quite powerful server as a result. HAP is far less compressed and does not use any temporal compression to my knowledge.This makes it far easier for the server to render those files while the CPU is almost asleep. I'm not aware of any settings in ffmpeg to increase compression.

I don't know whether it works on your OS-X version but I've installed AVF Batch Converter on my OS-X 10.10 and it exports all the formats I usually need including chunks for HAP files.

Am I right assuming that there is no cut between media files at the connection between LED 1, 2 and 3, i.e. the media is not split at this spot? What I would try is to use two outputs from one server and two outputs from the second server on ONE led first. Then you can see whether the outputs are framelocked between two servers. The difference is that all outputs would have the same orientation and resolution in this case. What hits my eye is that the centre led seems to have a different orientation, i.e. the screens here are rotated. Is this the case? This could be one reason for your problems since displays (led screens too) usually have some sort of scan direction.We've seen this often when rotating LCD or plasma displays by 90° where we had the same problem of small offsets. Led screens usually have much higher scan rates but it could still show a problem in fast movements. You could then check whether there is a difference if you use your outputs all in landscape orientation. Since the centre part is higher than 1080 or 1200, you'd need to tile your outputs with two rows of display. Secondly I would not use non-standard resolutions either. We have seen issues with NOVA controllers with source resolutions different from 1080p. Lastly we have been involved i a show recently where we used three outputs on three processors driving one big led wall. The outputs were synced with a S400 card and the AnalogWay Ascender in between us and the led display was also in sync. The led processors had a framelock function which was not set correctly and this led to very visible sync issues between the three processors. Once it was set correctly, the wall looked fine.

Another hint maybe: try with 6.2.2 or 6.3.1 first.

I've seen H.264 files failing before and the reason was an unsupported encoding level. This could be your problem as well. Dataton has only limited options to cure this since it is a problem of the third party decoder used in the program. You can check this with software like MediaInfo or VideoSpec (both OS-X) or similar programs you might find for Windows OS.

The production computer can be any computer capable of running Windows 7 or newer. I personally like using powerful notebooks since they are portable and flexible, can be taken back to the hotel room and have a UPS built in by design. The network can be any 1Gbit network, preferably using unmanaged switches. Managed switches are ok as well if you know how to set them up. If you have a lot of content in HAP or image sequences you'd rather select a desktop or 19" rack mount pc with 10Gbit network cards and a 10Gbit network infrastructure. The display units are the display computers, e.g. WATCHPAX, WATCHMAX or similar builds.

Hmmmm.... start reading the manual from A-Z and all in this forum. Alternatively enroll into a WATCHOUT Certified Training session.

I haven't done it with Nvidea for quite a while but maybe you can check the two pages under "video". If you come across something like 16-255 or the like, this is the place to change it.

Have you checked the settings for the colour range. I remember NVidea cards used to go from 16-255 instead of 0-255. You can change this in the graphic card settings.

This is the behavior if you change it in the preferences. Preference changes are something which works like a preparative preset for your show, not something you change during a presentation. You can though change the conditional layer status from outside through telnet at any time while the show is running, e.g. through a control system (WATCHNET, BLOCKS, Medialon, Universe,...). You could also send strings from a timeline to change the selection while the show is running.

Simple answer, this feature was introduced in WATCHOUT 6. You can't export WATCHNET bundles in WATCHOUT 5.

It very much looks like a network issue and probably it is not WATCHPOINT generating the issue but the underlying Windows OS. I found some hints on SSL on the web which does not make sense here, but you should check whether you only use one NIC on both the production side and the display computer. Are both computers running Windows 10? Have you been able to use the computer(s) with WATCHOUT before? Is the firewall turned off on both ends? We have seen cases with Windows 10 where you'd need to turn the firewall on at first, then connect WATCHOUT (online) and tell the firewall that you want those ports to be open and then turn the firewall off again. It wouldn't work when the firewall was off right from the beginning.

Yes and no. It depends on the reading speed of the data drive in the production computer. In theory a 10 Gbit network can deliver appr. 1,280 MB/s. A standard SATA-III drive in a notebook will read maybe 500MB/s. If your production computer has a raid 0 of at least 3 SATA-III driver or a fast M.2 (NVMe) drive it will speed the transfer up. Of course, your display computers need a 10Gbit network card as well.

The WATCHNET manual tells you how to use hex code: HINT: As in WATCHOUT, it is possible to send hexadecimal data bytes by using the prefix “$” followed by two characters that specify a byte. For example, “$0D” will send a carriage return. It is possible to mix text messages with hexadecimal bytes in any order. Any number of hexadecimal bytes may be sent but each two character sequence defining a byte must be prefixed with the “$” symbol. So use the form $FF$FF............$0D

Yes. WATCHOUT can only work with one GPU. The onboard GPU needs to be disabled in bios or Windows drivers. Preferably bios.

I'm not sure whether I really get your question. From your screenshots, you're using a computer with two different monitors with native resolutions of 1920x1200 (MIG) and 1920x1080 (mobile). If you want to use this computer as a display computer, you can use both outputs in WATCHOUT. Both have the same IP number but the output numbers differ (1, 2). Or do you use a computer with a graphic card (WX7100) and an onboard graphic card. In this case, you'll need to disable the onboard graphic card in your bios settings.

Smooth playback depends mostly on file size, hardware specs and computer tweaking. I assume that your server is completely tweaked following the tweaking guidelines for Win 7!? Are your SSDs using RAID-0 configuration - and is WATCHOUT installed on this SSD raid? Is your OS on a separate SSD or at least on a separate partition? Have you checked the reading speed of your WATCHOUT SSD? Since you're using an 8-core CPU it might be a good idea to use chunks when encoding HAP.

I've not seen WATCHOUT production crashing when too many videos had to be rendered. It usually slows down a lot and working with cues gets lagging. But the Windows protocols could show more information about the cause of your issues. Alex is pointing to an issue which usually happens when more than one NIC is active. In this case the production software will roll the timeline but the display computer will not react. In your case, the gui of the production software was blocked, wasn't it?

It looks a bit like a fault on your production computer. Has it been tweaked (basic tweaks)? Which OS are you running?What sort of graphic card are you using on the production computer? Pre-loading 12 timelines can put some work on the production computer since it needs to render all the content of the stage window at the same time while usually the graphic power of notebooks is not the highest. If you have a lot of displays and maybe even more than one display computer, the display engine in WATCHMAKER has to do the work of the complete cluster to render the content. A good way to handle this is to switch the stage window to show thumbnails only instead of videos in highest possible quality. Once the show is programmed it is usually not necessary to see the videos running in the stage window. This reduces the load on the production computer quite a lot. The log files do not seem to show any information about the crash on April 12th. You could maybe check the events of the Windows log files. Maybe you'll find some hint in there.