joakim

Hi Francis. That makes senare because the spark sends NDI HX whereas the scan converter sends normal NDI. If you make sure HX is installed on the media server then it will work from the Spark as well. Best, Joakim

HI Francis, The splash screen that you are seeing occurs when you try to play an NDI HX stream on a computer that does not have NDI HX installed. To deploy NDI HX to the display computers you must have have it installed via the WATCHOUT installer on the production computer. It is then installed as a part of the update process. Best, Joakim

Hi JEdgerly, As of now the SDI output support is limited to WATCHPAX 60 model C. Best, Joakim

Hi Ectoplasmosis, Resolutions, We have conducted further testing and concluded that the transfer speed of media files in WATCHOUT has indeed become worse in 6.4.1 than it was in 6.3.1. The issue seems to be related to both how many displays are connected to a display computer and to the resolution of these displays. It does not seem to make a difference wether the connected displays are used in the show or not. We are of course working on a solution but until a solution is found and deployed I can only advise you to use fever displays while transferring media. Best, Joakim

Hi Ectoplasmosis, Ok, for the files you are describing you should definately see transfer speeds higher than 300MBit/s. Have you seen similar behaviour in earlier versions of WATCHOUT or is 6.4.1 the only one you've tried? I will attempt to reproduce the problem here at Dataton. Best, Joakim

Hi Ectoplasmosis, What type of files & how many are you transferring via WATCHOUT transfer mechnism? The reason I ask is because WATCHOUT does more than simply transfer files, it also does analysis etc. This is not something that Windows network sharing does and could be the cause of the differences you're seeing. Best, Joakim

Hi Brighter, Your conclusion that the software is not waiting long enough for the display computer to enter desktop mode is correct. This is not a problem that is exclusive to WATCHOUT 6.4.1 but rather something that is present in the software used for remote desktop access. We are looking into the problem but as of now the workaround is to wait until WATCHOUT has gone into desktop mode and then try to establish the connection, or to continuously try to establish a remote desktop connnection until it works. Best, Joakim

Dear Olof, Sadly Mike is correct, there is no way to export/import single panels, scripts, etc. between WATCHNET servers. Right now the only option is to completely replace the setup of one server with that of another by replacing the WATCHNET_Data folder. Best, Joakim

Hi Guy, Which browser and which version of that browser are you using? Some older browsers have issues uploading files larger than 2GB and since your uploading stops at 3% of 80GB (which is 2.4GB) i suspect that may be the issue. You could try with another / a newer version of a browser. Best, Joakim

Hi Shane, I've tried to reproduce your issue using WATCHNET (1.4) and WATCHOUT (6.2.2) and I cannot get the error you mention. If I create multiple named control cues, either on the main timeline or on an auxiliary timeline (task), I can jump between them using either buttons that do it directly or scripts and get the correct results. I cannot see any difference using STOP or RUN together with the jump action. One thing that I can think of that could cause these issues is if you have multiple control cues with the same name in a timeline. Could I ask you to send an email to support tagged with WATCHNET and provide links to your shows (both WATCHNET and WATCHOUT) and I can investigate further? Best, Joakim

Hi, I think the culprit here is line 5 of the WATCHNET log: "Cluster error". Could you please send an email to support tagged with WATCHNET and attach the log files from WATCHOUT production and WATCHNET and we will dig deeper into this issue. Best, Joakim

Hi, The [Error 7 0 "Unrecognized Command: Discover"] is reported by the production computer because WATCHNET broadcasts a discover message on the UDP port that the production computer listens on. The reason that the error is logged is as Rainer pointed out the WATCHOUT 6.2 or later is required for the network discovery to work, earlier versions will log this error instead. The error in itself will not cause any problems for WATCHNET or for the production computer, the only effect is that the production computer will not be discoverable by WATCHNET. When it comes to controlling a production computer that cannot be discovered on the network, the IP address of the production computer must be manually entered as you did but you must also enable TCP connections for the current show. This is done in preferences right next to where UDP control is enabled and is required because WATCHNET uses UDP for discovery mechanisms but TCP for the actual show control. Since you're using an older version of WATCHOUT production I would suggest enabling TCP control and disabling UDP control for the current show. This will allow you to control the production interface and should stop the unrecognised command errors from appearing as the production computer will not be listening on that port any more. Best, Joakim

Hi, While it is technically possible, but highly complicated, to make WN send SSH commands I would advise against it for security reasons. There is no support for encrypted communication channels with external devices from WATCHNET so any ssh server would have to be configured to accept "none" as its cipher-type for connections and any communication would therefore be sent as clear-text. Best, Joakim

Hi Jakub, When WATCHNET prompts you for a user admin password and a "Spec_bad_####" file is created it means that WATCHNET was unable to load the previous Spec file correctly and could not recover the data within. This usually happens if you've downgraded WATCHNET (e.g. moving from 1.4 to 1.3) since Spec files are generally not backwards compatible. If this is the case you can restore the previous version of WATCHNET and remove the current "Spec" and "Cache" files and rename the "Spec_bad_###" file to "Spec" and then start WATCHNET. Best, Joakim

Hi, Good to hear the "fix" works to bring back the script page. I cannot give you an exact date for the new release since a lot of testing remains but it will be shortly, within a few week(s) is the best I can give you. Best, Joakim

Hi, I've investigated the issue and as far as I can see it is caused when a device is deleted or renamed while still being used by a script. The issue is resolved and the fix will be included in the next release of WATCHNET which is due for release shortly. In the meantime, try restarting the server and entering the script page again. If that does not work, try adding a device with the same name, and group affiliation, as the one you removed, and enter the script page again to remove the script actions using that device. Then you can remove the device again. Best, Joakim

Hi, The issue has now been resolved, it was caused by having his two display computers configured as two separate clusters within the same show. Calling load show on one cluster therefore attempted to load the show on the other cluster (display computer) as well which caused the active auxiliary timeline to be stopped. Resolved by configuring the two display computers as belonging to the same cluster. Best, Joakim

Hi Kevin, I realise this is vital information that is needed in a live environment. What I was getting at is that there are ways of executing events relative to the current time of a timeline even if the information is not possible to display, e.g. through WATCHNET scripts. Best, Joakim

Hi, Sadly no, this information is not possible to display on a WATCHNET panel at the moment. May I ask why you need to manually read the current time of a timeline? I'm asking so that I can maybe help you find a work-around if you don't wish to / can't use the remote app. Best, Joakim

Hi Fisejs, The first error you mentioned: "AxProtector Java Error" is a known issue that originates from the license protection of the WATCHNET software and we are investigating the issue. Should you encounter this error again, the recommended solution is to restart the WATCHNET server and try again. This process may, on rare occasions, need to be repeated a few times until the server operates normally. The second error: "ERROR REST" occurs, as you noted, when a user enters a section which has restricted access. As the user enters that section an attempt is made to fetch the contents of that section from the server As the user is not logged it yet an error message is generated on the server and an "UNAUTHORISED" message is sent back to the client which brings up the browser login-form. The error message on the server indicates that an unauthorised attempt to fetch data was made but it will not cause any other errors to occur and once a client has logged in using the browser login-form no more errors are generated and everything works as expected. We have also noted that the newest version of Chrome continuously tries to fetch data while the login-process is in action which will generate additional error messages on the server until the client either logs in or cancels the login-process. This will clutter the error log of WATCHNET but will not cause normal operations to fail. I hope this answers your questions. Best, Joakim

This issue has now been resolved and in case anyone else encounters a similar problem I thought I would post the solution. An IP-Camera software called "HTWViewer" was running on the same machine as the WATCHNET server. This caused unexpected port-binding issues which meant that WATCHNET neither started properly, nor failed to start, but was rather stuck in the initialisation process. After removing the IP-Camera software everything works again.

Hi Jim, Yes this is verified and does work, but only when sending the commands over UDP. When WATCHNET is controlling watchpoint the TCP connection is blocked.

Hi SFluster. It is indeed possible to trigger the standby mode of WATCHOUT through WATCHNET. Set up your WATCHOUT main display server as an external device communicating using UDP, port 3039, and send the appropriate command. A list of available commands can be found in the WATCHOUT manual in the "Control Protocol" section. I've also attached an exported device from WATCHNET (in txt format) that you can import and start using. It contains the command you want, both hardcoded and by using parameters. Watchout.txt