PhilMarquis Posted August 1, 2019 Report Share Posted August 1, 2019 Hello guys, We have experienced what we think is a very particular bug and thought it would be great to share it with you for a future fix. Here's the info. Setup: Watchout 6.4 and 6.4.1 (updating to 6.4.1 didn't fix the issue) Producer: Sony Vaio - Model SF15A190S Displays: Windows 7 Home Premium ASROCK x99 extreme4 i7 5820 3.3Ghz w7100 16GB ram on board network adapter (1Gbps) Windows 7 Tweaking List applied Problem: When reaching a pause cue in an AUX Timeline, everything quickly flashes black. We are programming a 4200x1920 PNG file into a Virtual Display of the same size and then feeding to an array of 6 blended projectors. It seems to only be one PNG file that has the problem, but the troubleshooting did't fix that. The virtual display that feed the projectors are in the Main Timeline which is paused at 0:00.0. (We found that having virtual displays in the Main Timeline worked best in the past.) We had another display on another tier that was running as a backup and it was doing the same thing We have the habit of using a pause cue where needed, and adding play cues underneath the pause cue to add notes to ourselves. Troubleshoot that didn't fix the problem: -1- Changing/Rerendering the PNG file. Checking that it has 32bit color depth, that it has the same resolution as the other files. We even tried TGA, and JPEG without success. -2- Deleting the file from the displays so it is pushed again from the producer when updating. -3- Rebuilding show cache -4- Upgrading to 6.4.1 -5- Using another producer -6- Opening all UDP and TCP ports on all devices -7- Starting a whole new show and importing just the Displays, Virtual Displays, and Aux Timeline and some of the medias. Solutions: -1- When moving the show to the Main Timeline on layers above the Virtual Displays, it would stop flashing when reaching a pause cue. -2- When moving the Virtual Displays within the Aux Timeline of the show, it would stop as well. -3- Not using Virtual Displays at all and programming the medias in an Aux directly on the displays in the stage fixes the problem. -4- When keeping the Virtual Displays in the Main Timeline, and the show in the Aux like we usually do, and removing the Play cues that we use as notes underneath the pause cue, resolves the issue... -5- Also, having the play cue above the pause cue works. All in all it's an easy fix for a very particular case, but it really made us scratch our heads. Hope this can help users and maybe help you find a bug that can be fix in the future. Thank you! 0 Quote Link to comment Share on other sites More sharing options...
wiesemann Posted August 2, 2019 Report Share Posted August 2, 2019 For testing .... You could try putting a colorbar or something very visible beneath the problematic png(tif, jpg) in your main timeline. To check if it goes black or transparent. Had the same issues when trying to loop in an aux timeline without freerun-loop. 0 Quote Link to comment Share on other sites More sharing options...
Moderator jfk Posted August 3, 2019 Moderator Report Share Posted August 3, 2019 Two things that might be worth a try. In the media window, for the .png file causing an issue, change the Transparency setting from automatic to the correct setting for your image type. On the timeline, place the pause cue 0.1 seconds before the png cue ends. The 0.1 second delay it would cause when triggering the next cue should not be a big issue. This protects from an overrun condition that can occur from various network UDP conditions. After a pause is encountered, a second TCP gotToTime is automatically sent by the master, which can cause a jump back after an overrun. Note: another way to test for this is to run it in cluster mode vs production mode. If cluster mode cures it on the cluster master, than an overrun condition is likely. 0 Quote Link to comment Share on other sites More sharing options...
PhilMarquis Posted August 5, 2019 Author Report Share Posted August 5, 2019 On 8/2/2019 at 6:39 AM, wiesemann said: For testing .... You could try putting a colorbar or something very visible beneath the problematic png(tif, jpg) in your main timeline. To check if it goes black or transparent. Had the same issues when trying to loop in an aux timeline without freerun-loop. Yes it goes "transparent". I mean the media disappears for a second but I can see stuff underneath like you said. On 8/3/2019 at 11:15 AM, jfk said: Two things that might be worth a try. In the media window, for the .png file causing an issue, change the Transparency setting from automatic to the correct setting for your image type. On the timeline, place the pause cue 0.1 seconds before the png cue ends. The 0.1 second delay it would cause when triggering the next cue should not be a big issue. This protects from an overrun condition that can occur from various network UDP conditions. After a pause is encountered, a second TCP gotToTime is automatically sent by the master, which can cause a jump back after an overrun. Note: another way to test for this is to run it in cluster mode vs production mode. If cluster mode cures it on the cluster master, than an overrun condition is likely. We've already tested to see if it was a transparency setting issue. We tried all the options without sucess. Worth noting that's there is no transparency in the media. We have tried pausing as far as 5 seconds before anything coming to an end or anything new coming up. It wasn't the issue. The network seems good and like I mentionned, we have tried opening all UDP and TCP ports as inbound rules for the displays and outboud rules for the production in case it would be blocking somewhere. The ping is of less than a millisecond 0 Quote Link to comment Share on other sites More sharing options...
wiesemann Posted August 6, 2019 Report Share Posted August 6, 2019 Hi, I did not mean transparency within the media itself. I got that when you mentioned that you tried other formats. I meant, that when you say „flashing black“, it could be that it actually would show what is beneath it for a fraction of time. That is what I experience with aux-timeline-loops. 0 Quote Link to comment Share on other sites More sharing options...
PhilMarquis Posted August 6, 2019 Author Report Share Posted August 6, 2019 4 hours ago, wiesemann said: Hi, I did not mean transparency within the media itself. I got that when you mentioned that you tried other formats. I meant, that when you say „flashing black“, it could be that it actually would show what is beneath it for a fraction of time. That is what I experience with aux-timeline-loops. Yes it shows what's underneath. 0 Quote Link to comment Share on other sites More sharing options...
wiesemann Posted August 7, 2019 Report Share Posted August 7, 2019 The problem is that the only two workarounds are to either always have some timeline underneath covering up that „bug“ (cannot be a feature) or use „freerun“ for looping with aux-timelines. 0 Quote Link to comment Share on other sites More sharing options...
TimFranklin Posted August 8, 2019 Report Share Posted August 8, 2019 Did you have any opacity tweens on these cues? I had an issue similar to this and the solution was to give extra space between fade in / fade out opacity tween points. Gave it a second after the fade in and about .1 seconds before the fade out and totally fixed it. Make sure the pause cues are not exactly on top of any opacity tweens whatsoever. 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.