Jump to content

3rd Party UDP control issues with Watchout 6.2.2


basvantuijl

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

 

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...