jfk

This might help ... TN 3475 Ektapro Smartlink home build Never diagramed that one. If you want to use the correct connector for the SMARTPAX side, I believe they are still available. However, all my research was done when that connector was provided by AMP. AMP has since been sold, so the old AMP part numbers I have will be superseded by the new owner's part numbers. But here are the AMP part numbers to start from. Dataton SMARTPAX® female device connector -three parts, — receptacle, — pins for receptacle, and — outer squeeze to release (STR) shell AMP STR Female Cord Guard 745002-1, 745002-2 (part numbers for two different cable diameters for the cable strain relief ) AMP STR Receptacle housing 9 pin 207752-3 AMP pins for female 66504-9 There is a bit of a gotcha in the above. The pins require a precise tool for close to perfect crimping or they will never insert correctly into the receptacle. Even when crimping with the proper tool (AMP Pro Crimp PN 58448-2) if you do not get it just right, it will not insert correctly. binned a few for that reason

That is correct, the hardware is in the WATCHMAX so it will not show up in the production computer input hardware settings. The only input devices that will show up in the production computer are input hardware that is physically in the production computer, and this is exactly what you are seeing. When programming, you program the display server input behavior by defining a Live Video object from the Media menu and associating it referencing the WATCHOUT input number defined in the WATCHMAX. Be sure to leave preview set to thumbnail. You only set it to live video when there is capture hardware in the production computer and you are feeding the signal to that capture hardware in the production computer. ;) OK, this seems separate from your input issues and is less clear. Can you provide screen shots of the display configuration that is working and the ones not working? As expected. Your capture card inputs are not in your production computer and therefore will not show up in your production computer.

Contact Dataton Support and provide a description of your issue, request the beta that addresses it, and you can have it now. ( Dataton Support -https://dataton.atlassian.net/servicedesk/customer/portals )

No

Who at Dataton said that? Dataton is aware of issues with color conversion with new nVidia gpus, they are in the process of making changes to address this, it is in beta test now, and should be available in the near future.

Are you saying it used to run without issue and this is now changed? if so, system attacked?

Are you reading timecode with another software on your WATCHOUT computer? If so, that may make the audio input unavailable to WATCHOUT.

No, anytime you transfer content the show will pause. The solution is to bring in content that does not arrive until after a show has started in another way. i.e. you must still prepare for it in advance. Using live tweens and live video input you could bring in content from another source and scale and position it using live tweens … Give your client a choice, provide all content by a reasonable deadline and then provide him the extra cost for content arriving after said deadline.

Simple answer is yes, all WATCHOUT License USB keys are upgradeable. The cost will vary depending on the age / version of the older key. https://knowledge.dataton.com/knowledge/the-difference-between-different-watchout-keys-and-versions

Great suggestion. Any ideas on what those sections should be?

Sounds normal. The timeline is calibrated in clock / stopwatch time, not timecode time. With NTSC 29.97, drop or non-drop, the timecode time will NOT match clock / stopwatch time - that inaccuracy is inherent to NTSC timecode. If you want to see timeline position in NTSC timecode format, add a status timeline position display, double click on the time readout, and change the display to the matching timecode type.

NO! Microsoft DirectX is part of Windows, it is already there. WATCHOUT would not run without it. Microsoft DirectX multi-output only supports physical outputs from one graphics card. If you require six outputs, then you must use a single graphics card with six outputs.

WATCHOUT uses Microsoft DirectX multiple output support. That method only supports outputs from one graphics card. While the processing power of the second card is utilized, you can only use the outputs from a single card. ie what you observed is expected / normal.

Are you trying to use MIDI Show Control to run the main timemine (ignore cuelist value) or aux tumelines (map cuelist value)? You can not do both with ETC. The setting of the MIDI Show Control “MSC Cue Lists:” popup is critical to how cue lists are mapped. I also seem to recall an offset in a value when using an EOS, but it has been so many years i can not remember which one. I also ran across ETC consoles where the user interface provided MIDI settings, but the internal MIDI module was not installed, but again in excess of 5 years ago. Also, WATCHOUT performs a string comparison for cue values, not a numeric comparison. This is done to support cue vales like 2.6.1, which some consoles permit, and there is no numeric value for a number with two decimal points / dots. So if the console transmits cue number 3 as 3.0, you must enter the control cue name as 3.0 to string match. (Can’t remember which console does it that way. Flying Pig comes to mind though.)

Sure sounds like a Windows preparation issue.

Not a lot of information there. Your screen shot shows offline, but not in Standby, please provide more information on the circumstances preceding the “freeze” and describe what you mean by “freeze”? Guess 1 Had a customer whose production server would worked flawlessly in editing and cue to cue run through, but would freeze during a show when waiting in pause for the point in the live presenters script to trigger the next cue. Turns out the run throughs never paused as long as the real shows, and a prolonged pause convinced Windows that a period of inactivity is occurring and low priority background tasks would kick-in, crashing WATCHOUT. Of course, a properly prepared server has those things disabled. ie improperly prepared Windows system Problem: improperly prepared production server Solution: Clean install of Windows and required drivers, run the tuning list completely and correctly.

BTW reducing the WATCHOUT Display / projector refresh rate would likely make it worse. Either run the camera at a slower refresh rate or lock the server and camera to a common reference.

You are correct, most likely your camera is at 60 fps and it is not in synch with the WATCHOUT Display output. Reducing your cameras rate to 30 fps is a potential solution. If you must record at 60fps, a WATCHPAX 60B or 60C contains a hardware synch card (or any server with a hardware synch card) that can be genlocked to house reference which would also require you to genlock the camera as well.

Is the WATCHOUT 6 test on the same computer?

The most common cause is a second network interface in the production computer. Your description exactly matches that issue. Did someone activate WiFi in your production computer recently? If you require two NICs, then the WATCHOUT NIC must be the first NIC in Windows NIC order to prevent this. If there is only one NIC, this issue will not occur. If you search the forum, you will find numerous posts with this issue. A recent post in the responses even includes info on how to change Windows NIC order in Win 10. There are other potential causes for what you describe, but your post indicates you have already eliminated those issues.

A very qualified yes. The mp4 codec has many option settings and those parameters can significantly affect stability. For example, an mp4 with bi-directional frames will probably play ok once in a quick test, but run that same file over and over again over the course of a day and it will often take the server down. The encoding setrings for mp4 are similar to mp2, so the details described in this article apply to mp4 as well. reference: https://knowledge.dataton.com/knowledge/how-to-encode

Before considering MacOS issues, are you sure you have the correct license for WATCHNET? reference:

You might have better results asking the question here … https://forums.presonus.com/viewforum.php?f=357

localHost is always the device itself. So are you saying the iPad can not see itself? Otherwise, while the server computer running a browser can see the local server as localHost, any other device on the network (like an iPad) must use the valid network address of fhe Network Interface of the server.

It is probably not the issue, but to rule it out, did you check the audio output assignments in each audio cue on the aux timeline?