RBeddig

Some HDMI converters know two versions of SDI. I recently had to play with the settings of my Decimator interfaces until I found the right combination.

Hello Ryan, Two things to consider here. a) Blackmagic graphic cards are unfortunately not the best choice since the cards drivers usually don't analyse the input signal format and one usually needs to play with the driver settings of the Blackmagic software and the settings in the input in WATCHOUT for a while to get those cards working. More professional cards like those from Datapath identify incoming signals correctly and it usually doesn't make much difference if the settings in WATCHOUT are wrong. They will still show an image. We have seen cases where we needed to set the input in WATCHOUT to e.g. 720p25 when the source sent signals at 720i50 etc. b) Testing the signal from a DVD on a Blueray player might not be the best idea. Blueray players usually use DRM coded outputs which will usually work on monitor inputs but never on capture cards, no matter what product. The manufacturers of capture cards are usually not allowed to capture content from DRM protected outputs. The better source would be a camera with SDI output or a normal HDMI signal from a computer desktop converted using a HDMI > SDI converter. Hope it helps.

Thank you for sharing. I recently stumbled over an AE/ME/Premiere plug-in encoder for HAP which was until now unknown at least to me. We did some test encoding regarding banding and the slow encoding of this package looked better than the result of AfterCodecs. Check: https://jokyohapencoder.com/

From my experience, HDBase-T sometimes shows incompatibility issues between transmitters and receivers. Especially when it comes to older variants. The second point is that I never copy an EDID signal from a display since this includes all possible frequencies the display is capable of working with. I either use external EDID minders with only one frequency burnt in or the EDID settings of the graphic cards driver.

Do you have any other production computer for testing? It looks as if the problem is on that side.

WATCHPAX units are set to DHCP as default. What IP address do you see at the splash screen when the server starts? You can set an IP address when using a mouse and keyboard and the keys Ctrl + W. Look for the startup script in the File menu which explains where and how to do it. More important than the network list is actually whether you can connect to the server. In the screen settings dialogue box on the production computer there is a connect button which should turn green if the software "sees" the server and all necessary ports are open.

WATCHOUT manual page 172... Don't forget to define the MIDI device under preferences control.

I the show works fine using production computer A and shows errors using production computer B, the gear to investigate is the production computer. Are you using the same network cable and the same port of your switch when you swap the production computers? If not, do so to rule out faulty cables or broken ports on the switch. To analyze what's going on on the network, it could help to use Wireshark on the production computer. It will write millions of events in it's log list but you can easily filter out parts once you compare the time of the network loss.

Well, since I have not seen such a behavior and we have not heard of other cases so far, looking at the log files seems to be the only way to solve the problem. While in most cases, problems like this can be related to broken cache files or broken content files, it could of course be hardware related too. E.g., have you ever tested your RAM with something like https://www.memtest86.com/ I remember a case probably 14 years ago, when a client programmed a show with appr. 10 display computers and all of those did an unintended reboot after some 4-8 hours. Some earlier, some later. After long investigations, we found out that the RAM modules used in the server didn't work properly when more than one module was used. As the mainboard used quad-channel RAM architecture, there were of course 4 modules in the chassis. Taking three out made the system stable. The RAM was specified in the QVL list of the mainboard! We then changed the RAM to another product which we used at that time in our servers and that cured the issues.

If I understand it correctly, the show crashes on the production computer when the timeline reaches 25+ minutes? Have you checked the log files on the production computer? Have you checked the event log files (application) in Windows? Have you deleted the WATCHOUT cache file on the production computer so that it gets rebuilt? Can you rule out that some media at that point in the timeline is corrupt?

Could be difficult since you're just using a web browser to access WATCHNET. As in every other web project, there is no real mechanism built into WATCHNET to make another browser change the page. But this is standard web browser behavior.

If you can make it work under Windows and turn off all other NICs, it should work with WATCHOUT too. WATCHOUT does not have any adaptors!?

No, it should work the same.

Be aware not to set the actual clips to free running and looping if you place them into a composition. Then the composition needs to be set to free running and looping instead. To make sure that the composition has the right length in the end, I usually first place my cues into a normal timeline, then open an empty composition, then set the composition length to a value shorter than my cues. Finally I copy and paste the cues from the timeline into the composition where the ruler sits at 0:00. The composition will gain length according to the length of the copied cues automatically.

"free running" means just this: WATCHOUT is not controlling the media position when it is set to free running. It will only re-sync the cue when your timeline runs into the cue again. Since computers have their individual speed, they will fall out of sync over time since one computer works faster than the other.

It's described on page 22 of the current manual. Another way is described in the tweaking manual. This is using the Windows scheduler to load WATCHPOINT which you can then delay in the scheduler.

Have you tried to delay the loading of WATCHPOINT so that Windows has sorted out the NICs before WATCHPOINT loads?

Since you're software which this forum doesn't cover, the first test would be to check the behavior of your WATCHOUT display server when sending NDI over a known hardware encoder or the NDI scan converter. Run a video on a second computer and check that the signal is smooth in WATCHOUT. Once you've verified that WATCHOUT reads NDI data correctly, you'll need to investigate what your NDI software does and whether the odd resolution might add to the problem.

BTW, you can find more information on encoding in a few articles here: https://knowledge.dataton.com/knowledge/watchout#video-encoding

What hits my eye here is that you say that it is only one out of three servers showing this behavior. While encoding can still be an issue, maybe you're trying to run more videos on this server at the same time than on the others, I would probably still look deeper into the specific server, especially when WATCHPOINT creates a dump file. There are other log files in your computer which may give you a hint. Start the event viewer and check your application and system logs. Another attempt would be to strip down your show to just a few content files and test those for a while. Then add complexity step by step until you can reproduce the error.

The log files do not really help much here to find the cause. If it affects just one of three servers it could also be driver or hardware related. The good thing is that the crash created a dunp file which you can find in the dump folder next to your logs folder. I'd suggest to open a support case with some more details here: https://dataton.atlassian.net/servicedesk/customer/portal/35/group/35/create/43 And send the dump file to the support team. They have tools to analyze the dump file.

Sounds very strange. The only ideas which come to my mind here are. Could it be that WATCHPOINT is started twice and while one version plays your show, the other tries to grab your attention telling you that it is searching for a license key? What are the log files saying? You find those in a folder logs inside your WATCHOUT software installation folder.

Difficult. The good thing is that the mainboard and CPU seem to work (image on screen). Sending commands from the control system worked??? Maybe the first test for me would be to use PuTTY or PacketSender and send some commands to the unit, like authenticate 1 authenticate 1 ping or other commands which could give some indication of the status of WATCHPOINT (getStatus, load showxyz,...) If they see some of the expected reaction, the next step would probably be to connect mouse and keyboard and look into the Windows explorer on the data drive (Task Manager > New Task... > explorer). I would now check the show folder and it's content. Are the sizes of the media files as expected? Are they all there? One could drag the show to an external hard drive and check whether the video files actually play or are maybe corrupted due to the power outages. One should also check whether date and time are near the actual date and time on site. If they are years behind the CMOS battery might be dead.

Never seen this error but a quick Google search pointed at DHCP / DNS problems. Are you using any fixed IP addresses for your servers or DHCP? Have you checked whether the IP addresses shown on the initial splash screen of WATCHPOINT make sense in a way and are reachable from your production computer?

Then you should be able to do all this using the control API which is described on page 175 in the manual.