Jump to content
Dataton Forum

joakim

Moderator
  • Content Count

    20
  • Joined

  • Last visited

1 Follower

About joakim

  • Rank
     Dataton

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

484 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. joakim

    Watchnet

    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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...