basvantuijl Posted June 11, 2018 Report Share Posted June 11, 2018 Hi, I was hoping someone could help? We recently updated one of our clients sites to Watchout v6.2.2 (from 6.1.5) in order to utilise NDI. after the update, we found that the ‘gotoControl Cue’ UDP command no longer worked via our custom iPad control app. We were trying to control the first Display machine directly just like before. We we able to start auxiliary timelines, but any time we tried to jump to a point in the main time line, the image just flickered once, with no jump happening. We did also have issues with display machine 1 (of 3) not coming online properly, and being out of sync / not playing content properly. We tried 6.2.1 but still had the same issue. In the end we rolled back to 6.1 Has anyone experienced a similar issue or know what could be causing the problem? We tried to re-install and run 6.2.2 on the display machines as Administrator but it didn’t seem to make any difference. We didn’t go back online via the production machine after doing this (as the production PC had already been rolled back to 6.1 and we were running out of time) Any help anyone could provide would be greatly appreciated! Thanks, Bas 0 Quote Link to comment Share on other sites More sharing options...
Andrew Posted June 12, 2018 Report Share Posted June 12, 2018 I have a similar experience.I made the show with 6.1.5 and then updated it to 6.2.1.I used to bring up an existing show and got a problem.In 6.1.5 it was executed normally. However, in 6.2.1, a lot of contents were flickering or playback failed.I tried a lot but I could not solve it and I had to go back to 6.1.5. 0 Quote Link to comment Share on other sites More sharing options...
Dataton Partner RBeddig Posted June 12, 2018 Dataton Partner Report Share Posted June 12, 2018 Sounds more like a network issue. Could UDP be blocked somewhere? Could the UDP communication be going to a different network adaptor than the TCP commands? 0 Quote Link to comment Share on other sites More sharing options...
basvantuijl Posted June 13, 2018 Author Report Share Posted June 13, 2018 Hi, Definitely isn't a network issue, as nothing else has changed on the setup apart from the software version on the display / production machines. We are able to start auxiliary timelines but getting the exact same issues as Andrew mentioned in 6.2.2 on the main timeline. All display servers have only one network adapter enabled. Our automation controller first authenticates / loads the show via TCP, then sends timeline jump commands via UDP. Play / Pause commands sent via UDP appear to work correctly too. 0 Quote Link to comment Share on other sites More sharing options...
basvantuijl Posted July 2, 2018 Author Report Share Posted July 2, 2018 Hi, Has anyone experienced similar issues / come up with a resolution to this problem?. Thanks, Bas 0 Quote Link to comment Share on other sites More sharing options...
Alex Ramos Posted July 2, 2018 Report Share Posted July 2, 2018 I would create a new simple show from scratch to debug the system, network and or software. Make sure to also include aux timelines I have similar problems all the time. My productions all have 2 or more NIC. WO must always be started with only the WO NIC on, all other NICs must be off. I can turn it back on, but only after going online with WO. Tried a ton of things to try a solve this problem but never with success. This mater is something I'm waiting Dataton to address many years. We need a way to on WO address all traffic to a specific NIC or NICs in case of multiple cards in a system. 0 Quote Link to comment Share on other sites More sharing options...
basvantuijl Posted July 16, 2018 Author Report Share Posted July 16, 2018 Hi, Ok, I think I may have managed to work some of the issues out (i had to introduce a lot of delays to the commands). One of the display servers was still failing to play content correctly. I discovered that if I disable the audio output, it worked fine. As soon as I re-enable it, it locked up and wouldn't play the content correctly. I've tried updating the audio drivers but I can't get the video content to play back smoothly (when the audio output is enabled) and I can't seem to get any audio out of the machine at all. Could someone please confirm how I can get the audio to work properly? I'm just using the standard Realtek onboard audio (only require stereo audio). The audio is embedded in one of the videos playing on that server. worked fine before in 6.1.6 but I understand Watchout have made changes to the way audio works? I couldn't find any documentation on it though. Thanks, Bas 0 Quote Link to comment Share on other sites More sharing options...
nickelalloy Posted August 17, 2018 Report Share Posted August 17, 2018 I had exactly the same issue today. Watchout 6.2.2, using TCP commands to jump in the main timeline. I was using TCP to jump between multiple short video loops (20 Seconds), which were set to free running and looping. Triggering the TCP command would correctly jump to the control cue, the preview on the production machine would show the correct content, but the display machines would just sit there and flash the old clip, until I manually paused and then re-run the timeline. Didn't find a solution or a work around, thankfully we didn't need to use this control method in the actual show. As you say Bas, it works fine in aux timelines, but not on the main one. 0 Quote Link to comment Share on other sites More sharing options...
MatzeLe Posted October 3, 2018 Report Share Posted October 3, 2018 The same here, after updating from 6.1.6 to 6.2.2 the telnet commands don't work as before. I used to send a stack of commands like "authenticate, load show, gotocue, run" just with line seperators between as a single message, worked fine until the update. Seems there was a mechanism for stacking commands and execute them when ready. Interesting that it works on aux timelines, didn't test this. Another interesting observation was that cues on the beginning of the timeline where found right after load, whereas later cues needed some time after load to be found. My solution was implementing a bidirectional communication for load (waiting for ready answer) and use a standard break of 250ms between each command. 100ms was too short for auth->gotocue->run. So please Watchouters, make it work like before. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.