Jump to content
Dataton Forum


  • Content Count

  • Joined

  • Last visited

1 Follower

About joakim

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

702 profile views
  1. 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
  2. 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
  3. Hi JEdgerly, As of now the SDI output support is limited to WATCHPAX 60 model C. Best, Joakim
  4. 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, Joaki
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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 prod
  13. 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
  14. 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
  15. 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
  • Create New...