Runtimes Not Cueing/Taking after Win 8.1 --> Win 10 Upgrade

All other topics about Ventuz Director here.

Moderator: Support

Post Reply
dondi
Posts: 19
Joined: 08 Mar 2013, 22:11

Runtimes Not Cueing/Taking after Win 8.1 --> Win 10 Upgrade

Post by dondi » 09 May 2018, 23:30

Sorry in advance; this'll be a long post

Arrived onsite yesterday for a client using Director to drive two runtime machines for internal studio video wall. Client notifies me that they are having issues with the runtimes "losing focus" since upgrading the machines last month from Win 8.1 to Win 10. A Master/Backup configuration with local Director machine driving the runtimes on a 2880 x 840 video wall. nVidia Quadro K5000 cards with Live video (Black Magic) cards. I believe Erik B (and/or possibly A. Cooper) had originally supplied client with a generic template that can be populated with assets in Director for playout (JPGs, MP4s and live video are the bulk of the content for this client), originally running V4 and subsequently upgraded to V5. I've worked at this location several times over the past two years with no issues.

OBSERVED BEHAVIOR UPON ARRIVAL ONSITE (Client has sent-over to Karol a zipped file containing the A/V Config folder and two log files I threw-in from the backup runtime machine)
When starting the project and the runtimes boot:
• Director log window records a refresh rate mismatch (non-error) message with a >98% difference in rates
• Both runtimes start minimized to the task bar
• No red boxes or show-stopping errors in topology

When sending a Cue/Take from Director to Master & Backup:
• Both runtimes ignore Cue/Take commands from Director until you VNC into the machine and Maximize the Runtime Window from the task bar (only the desktop is currently being shown before this action)
....... — After Maximizing the window, the OnAir template is displayed, but only displaying correctly if it is a static background image. Only the frozen current frame of a movie file or live video is shown when maximized
• While viewing the runtime machine via VNC and its task manager open, the Runtime GPU usage in Task Manager is pinned at 99.8% while maximized and drops to around 10% when minimized

THINGS I TRIED WHILE TROUBLESHOOTING
• I ran a couple focus logging apps to see if there was another app stealing focus. None of these utilities reported that another application was stealing focus.
• There didn't seem to be any way to change the refresh rates of the K5000 cards from the only available refresh rate reported by the nVidia control panel apps.
• Tried setting the FPS in Director Config to both 29.97 and 59.94. The setting prior to all this was 59.94
• All notifications are turned off and firewall doesn't seem to be blocking VMS

PARTIAL SUCCESS AFTER THE FOLLOWING
Was able to get the BACKUP runtime to work after the following steps:
• Updated the nVidia Quadro K5000 drivers to the latest version
• Uninstalled and reinstalled Ventuz 5.04.116 (just a simple uninstall from SETTINGS --> APPS --> VENTUZ --> UNINSTALL. I didn't wipe the legacy files from C:\Users\...)
• In Director A/V Config, deleted the vid card and dragged vid card back. Set multisampling to MEDIUM and left the FPS as the default (none)
After these steps, the BACKUP runtime worked fine with a max GPU usage in Task Manager of 26% while maximized. All types of assets were functioning (JPGs, Live Video and MP4s). The runtime did not minimize itself at all and all templates were being pushed correctly from Director.

With the BACKUP working on the first day, we left everything alone for the next day (show day). We ran the show with no issues (except for the fact that MASTER was dead). After a successful show, we decided to take the same steps for MASTER as we did for BACKUP. After doing the same for MASTER, both machines reverted back to the same behavior at the start of the day prior. At this point we sent-off an email to Karol and I am to return tomorrow morning hoping to be armed with some good information to help fix the issues above. Any helpful "try this"/"try that" suggestions welcome. Hoping to avoid a fresh wipe/install of Windows 10, but not sure this is the case. If anyone has observed this behavior and has some suggestions, please post, or any helpful suggestions of something I'm missing. I think it odd I was able to get one of the machines to work after the above steps were taken and then both break again when taking same steps with the other machine.

User avatar
Karol
Posts: 514
Joined: 10 Jan 2012, 12:07

Re: Runtimes Not Cueing/Taking after Win 8.1 --> Win 10 Upgr

Post by Karol » 11 May 2018, 10:18

Hi Dondi!

I never heard of such strange behaviour.
And I have no explanation!
Is there any suspicious entry in the 'presenter.log' located in C:\Users\Public\Documents\Ventuz5\Log ?
Win 10 is pretty widespread now among our clients and we did not receive any complaints besides an IPv6 UDP issue (fixed since 5.3.2) and very rare Runtime minimizations (but not directly on start-up) caused by other applications.
Does this issue occur if you only run a single machine and the other is switched off?

Best Regards
Karol

dondi
Posts: 19
Joined: 08 Mar 2013, 22:11

Re: Runtimes Not Cueing/Taking after Win 8.1 --> Win 10 Upgr

Post by dondi » 11 May 2018, 12:10

I did battle all day at the client site to no avail. I performed "fresh" installs of Ventuz on all three machines (renaming the legacy Ventuz5 folder under C:\Users\Public Documents\ to BACKUPVentuz5 after the uninstall process leaving a "clean" Ventuz5 folder after reinstall and then copying the only client Project to all machines). Render layouts were recreated and all other AV settings in Ventuz Config setup on all. The runtime machines were originally setup using GROUP 0. I tried several topology configurations for the runtimes; as a single multi-machine cluster and also as individual cluster machines. One thought was maybe that GROUP 0 was interfering with the VMS communication with the runtimes, so I tried various combinations of assigning the runtimes both as GROUP 1 with different Machine IDs as well as trying to assign the runtimes their own GROUP ID # with Machine IDs of 1. I also tried a topology with just one runtime. Half the battle throughout the day was dealing with the program port constantly being disconnected because of the hash ID of the project being incorrect, etc. even though the same project was copied to all machines. I even at one point generated a new Project ID hash in designer and copied to all machines as well as creating a brand new Project using the original scene and copying that new project to all machines as the only project present in the Ventuz5\Projects hierarchy. (This scene was pretty old. When it opened in Designer the messages window was full of warnings for deprecated nodes. Mostly saying to use the Value Buffer, etc.). It was obvious that this was becoming a futile exercise. Both myself and the client were trying to avoid fresh Windows 10 installs, but we all have come to the conclusion that this seems to be the only path forward. So, all three machines are scheduled for fresh Windows 10 installs in the near future (and I believe a set of new templates coming from Kobbi is also in the works). Stay tuned

Post Reply