Skip to content
VideoPro
Support
SoftwareVP-TROUBLESHOOTINGDocumentation by Nevco

VideoPro — Troubleshooting

Model: VideoPro·Updated July 2026·~20 min read

Not yet verified. This guide was converted automatically from the official document and is awaiting review by our support team. If anything looks off — especially wiring, mounting, or safety steps — follow the official PDF or call us.

800.851.4040
Table of Contents (35 sections)

Something's wrong. Start here.

This section is symptom-first. You don't need to know whether the failure is in the Data Controller, the project, the signal chain, the OS permissions, or the streaming service; you only need to know what you're seeing. Pick the article below that matches your symptom.

  • If your symptom doesn't match an article above but you suspect your setup is wrong, compare it to a known-good Solution Recipe for your venue type. Recipes are end-to-end and make misconfiguration easier to spot.
  • If a Data Controller is the suspect, the catalog in Play and update graphics has per-controller troubleshooting tips deeper than what's here.
  • If output is the suspect (SDI vanished, Virtual Webcam missing, stream won't connect), Set up your production has the configuration reference for every Program Out destination.

A graphic that plays cleanly in the Designer Preview but flickers in VideoPro's Program Monitor almost always has one of two causes. Check each.

The Pause marker tells the cache where the graphic's "hold" state is — what should be on air after the entry animation finishes. If a layer ends or begins within a frame or two of the Pause marker, the cache has almost no content on either side of the pause and the layer can flicker as the cache transitions in or out.

To check:

  1. Open the graphic in the Designer.
  2. Look at the timeline. Find the Pause marker in the marker strip at the top of the timeline.
  3. Walk down each layer and check whether any layer's start or end sits within one or two frames of the marker.
  4. If you find one, either:
    • Move the layer's start or end further from the Pause marker (drag the edge of the layer track in the timeline), or
    • Move the Pause marker (right-click the existing marker, remove it, then right-click at the new position and add a new Add Pause Point).
  5. Re-cache the graphic in VideoPro and play it on air to confirm the flicker is gone.

The Optimize Timing tool also catches this and may automatically move the Pause marker one frame earlier to avoid flicker. If you've already optimized and still see flicker, the optimization may have hit a layer that needs manual adjustment.

Each variable in a graphic accepts one value. If two external sources both push values to the same variable, the variable updates whichever arrived last — and if both keep updating, the layer flickers between the two values.

This usually happens one of two ways:

  • A Tables data column has the same name as a variable in the graphic, so it auto-binds; AND a Data Controller variable was also bound to the same graphic variable through Link Data. Both push, both win in alternation.
  • Two Data Controllers are bound to the same layer, each providing its own value for the same variable.

To check:

  1. Stop the playback.
  2. Open Link Data on the layer (the icon at the left edge of the Preview panel).
  3. In the Link Data view, find the graphic variable that's flickering and confirm that exactly one external source is bound to it.
  4. If more than one is bound, remove the binding you don't want.
  5. For Tables auto-bind: rename either the data column or the graphic variable so they no longer match, OR explicitly bind the variable in Link Data to the source you want (the explicit binding takes precedence over auto-bind).
  6. Re-cache and play the graphic on air to confirm.

Use this when a graphic, data binding, or playback action doesn't do what you expected and you can't tell why from the Project List and Program Monitor alone. The Message Log records what VideoPro thinks is happening; recording the run captures the exact sequence so you (or NewBlue support) can play it back later.

The Message Log is a dock panel that records the actions VideoPro took on each graphic — when the cache built, when a Data Controller pushed a value, when a layer played in or out, when a graphic was taken on or off air. Reading the log is the fastest way to see whether a misbehaviour is upstream (a value never arrived, the wrong value arrived) or downstream (the value arrived correctly but the graphic didn't respond as expected).

  1. Open View > Message Log. The dock appears (default position: right side, tabbed with related dialogs).
  2. The newest events appear at the bottom. Scroll back to find the moment the problem started.

The Log doesn't have severity levels — every entry is an event, not a warning or error. What you're looking for is whether something that should have happened is missing, or whether something that did happen doesn't match what you expected.

For a full guide to reading the columns and recognizing common action patterns, see Read the Message Log.

If you can reproduce the problem on demand, the fastest path to a resolution is sending NewBlue support enough material to reproduce it on their side: the project file, the graphics it references, and a Support Package that captures VideoPro's recent logs and diagnostic state.

  1. Reproduce the problem so it's fresh in the logs.
  2. With the problem visible (or having just occurred), open Help > Create Support Package. VideoPro writes a zip file containing recent logs, system information, and project state. Save it where you can find it.
  3. Open File > Save Project As… and pick VideoPro project with Assets from the Save as type dropdown — that filter bundles the current project together with the graphics, fonts, and media it references into a single archive. (You can also use File > Export Project… for a packaged copy.)
  4. Send both files — the Support Package zip and the packaged project — to NewBlue support along with a written description of:
    • What you expected to happen.
    • What actually happened.
    • The sequence of actions that triggered the problem.

For details on what's in a Support Package and how to handle crash cases, see Create a Support Package.

The Message Log is a dock panel in VideoPro that lists every Data Controller action the scheduler dispatches. Each row records the moment the action was logged, the moment it was cued to play, the title it targeted, the variables it carried, and the action command that ran. Read it when a graphic plays on the wrong cue, plays with the wrong values, or doesn't play at all — the row that should describe the take is the row that explains the problem.

Open View > Message Log. The dock appears tabified with Properties and (on VideoPro Live) Audio Visualizer. Drag it out and dock it where you can see it during a show — the dock is hidden by default but its runtime cost is small once visible.

The dock has five columns:

  • Log — wall-clock time the action was dispatched, in hh:mm:ss.zzz format.
  • Time — the cue time the action was scheduled to play, in hh:mm:ss.zzz format. When Log and Time match, the action played immediately; when they differ, the action was queued ahead.
  • Graphics — the title the action targeted. VideoPro resolves the underlying GUID into the title's display name automatically.
  • Variables — every variable carried by the action, written as name = value pairs separated by ;.
  • Actions — the action command, expanded from its internal flags into a readable string such as alert, update, cut, or play+setvars+setintemplate.

The table holds the most recent 1000 rows. When it fills, the oldest row drops off the top. For longer captures, use Record (see below).

The Actions column is the column you read first. The names come from the Data Controller action vocabulary:

  • alert — the standard bring-up: animate in, hold, then animate out. Most one-shot lower thirds and scoreboard takes appear as alert.
  • cutin / cutout — a hard take to the hold point, or a hard take off.
  • animatein / animateout — animate in or out without a duration. Bring up an overlay and leave it; bring it down later.
  • update — refresh a value on a graphic that's on air. Animates off, then back on with the new values.
  • cut — refresh a value on a graphic that's on air, with no animation between old and new.
  • set / prep / snapshot / still — preload or pre-render a value without playing it.
  • playonce / tightloop / loop — single-shot or looping playback.

Combined commands appear as a +-separated list. alert+sync is an Alert with cross-layer sync; update+replace is an update that replaced an earlier pending action. The compound form is normal; decode it only when chasing a specific anomaly.

A few patterns recur often enough to recognize on sight.

  • The graphic didn't play. Search the Graphics column for the title name. If you don't find a row near the cue time, the action never reached the scheduler — the data controller didn't fire, the queue name is wrong, or the binding is misconfigured. If you do find a row but the take didn't come on air, check the Actions column for override or replace — something queued after it cancelled it out.
  • The graphic played with the wrong values. Find the row, then read the Variables column. The values shown are the values the scheduler dispatched. If they're wrong here, the problem is upstream in the data source or the binding, not in playback.
  • The graphic played late. Compare Log and Time. If Time trails Log, the action waited in the queue. Repeated rows with Render_Wait in the Actions column mean the render pipeline couldn't keep up; repeated rows with renderskip mean the system gave up waiting and played the held still frame.
  • The graphic was interrupted. interrupt in the Actions column means another action killed the current take to start. If that's unexpected, find what fired the interrupt.

Two checkboxes and a button live along the bottom edge:

  • Auto Scroll — when on, the table scrolls to the newest row on every insert. Leave it on during a show. Turn it off when you want to read a specific window of rows without the table moving under you.
  • Record — turns on full action-stream capture (see the next section).
  • Clear Log — empties the table immediately. Use it between rehearsal segments to give yourself a clean window for the next take.

The dock has no severity filter and no text filter. To narrow the view, clear the log, reproduce the moment, then read the resulting short capture.

When a problem only happens occasionally, the Message Log dock is not the right artifact — its 1000-row cap will drop the evidence. Use the Record checkbox instead:

  1. Tick Record. VideoPro starts capturing every dispatched action to an in-memory file.
  2. Run the show, or reproduce the problem.
  3. Untick Record. A Save dialog appears titled Save Recorded Message Log. Save the capture as an .nbaseq file somewhere you can find it.

The .nbaseq file holds the complete action stream — not just the last 1000 rows — and NewBlue support can replay it against your project to reproduce the run on their side.

Attach the .nbaseq file to your support email together with a Support Package and the project bundle. See Create a Support Package for the full procedure. The Message Log records what VideoPro did; the Support Package records what VideoPro thought; together they tell support what to fix.

For when to create the package and what to attach to a support ticket, see Send diagnostics to NewBlue Support.

The Audio Visualizer is a diagnostic panel that draws every audio source, every mixer bus, and every output in your show in one picture, with the live signal flowing through each connection. It answers questions like why is there no audio on air?, why is there echo?, why does the audio sound glitchy?, and why does one source sit at a different level from the rest?

Open the View menu and choose Audio Visualizer. The panel appears as a tab next to the Message Log; drag the tab out for a floating window.

Three columns connected by curved lines.

"The Audio Visualizer — Sources

Sources (left) lists every live audio source — microphones, NDI feeds, capture devices, Zoom callers, video clips with audio. Each source shows its name, L and R meter bars with a dB readout, input trim and mix levels in dB when set, and a latency bar that tracks how much audio is in the buffer queue.

Mixer Buses (center) lists every bus the channel routes through — Program, Monitor, Zoom, ISO, Stream, SRT. Each bus shows its master level, L/R meters, and mute state.

Outputs (right) lists every output device — Display, NDI, SDI, recording, streaming — paired with the bus that feeds it.

Connection lines between the columns tell you the routing at a glance:

  • Solid colored line: the source is feeding that bus. Color tracks level — green below -12 dB, yellow between -12 dB and -3 dB, red above -3 dB.
  • Dashed red line with an X: the source is excluded from that bus (a mix-minus). This is normal for Zoom audio routed away from the Zoom bus.
  • Dashed dim line into an output: that output doesn't carry audio.

A Channel selector at the top filters to one channel or shows all. In an all-channels view, buses are labeled Ch1: Program, Ch2: Program, and so on; the Monitor bus is global and shown once.

Below the diagram, the Raw Audio Report button expands a text-only diagnostic dump with per-instance buffer counts, underrun and overrun seconds, and the watermarks tracked since the panel opened. Both views refresh continuously while the panel is open.

No audio on air. Look for a source with green meters whose line to the Program bus is dashed-red — that source is muted on Program. Check the Program bus for its own mute indicator. If Program shows level but no output column has a solid line in, no output is routed to Program.

Echo or feedback in Zoom. Trace the connection from any non-Zoom source to the Zoom bus. It should be dashed-red. A solid line into the Zoom bus from a microphone or Program source is the echo path — fix it in the Zoom integration's mix-minus settings.

Clipping. Watch for source meters in the red. A red border with a non-zero error count means the buffer is also overrunning. Lower the trim on the source, not the mix level on the bus.

One source quieter than the rest. Compare the Trim and Mix readouts across sources. Two sources at the same on-air loudness will have similar trims; a -20 dB trim against a 0 dB trim is a misconfigured input.

Glitches or dropouts. Watch the latency bar under each source. If the filled bar runs well past the dashed target marker, or far short of it, the source is drifting against the mixer clock. The bar turns yellow as drift grows and red when it's critical. A single source in red while everyone else stays green points at that source's driver or network.

  • The Audio Mixer — set trims, mix levels, and per-source mute. The Audio Visualizer reads what the mixer is doing; the mixer is where you change it.
  • Report a problem with a support package — when an audio issue isn't obvious from the visualizer, the support package captures the same diagnostic data for the support team.

When something in VideoPro doesn't behave the way the docs say it should, the fastest way to get help is a Support Package — a single zip file that bundles the application's recent logs, system information, and your last saved project file so NewBlue support can reproduce and diagnose the problem without a back-and-forth.

This article covers two cases: a persistent problem you can demonstrate, and a crash.

  1. Leave the problem in front of you. Don't close the project or restart VideoPro.
  2. Open Help > Create Support Package.
  3. VideoPro opens a file dialog asking where to save the zip. Pick a location you can find easily.
  4. Wait for the package to finish writing. Larger projects with longer log histories take longer.
  5. Email the zip to support@newblueinc.com along with a written description of:
    • What you were doing when the problem started.
    • What you expected to happen.
    • What actually happened.
    • Whether it happens every time or only sometimes.
    • Whether anything in particular triggers it (a specific graphic, a specific Data Controller, an output, a particular sequence of events).

The support team will need that description as much as the logs — the logs say what VideoPro did, the description says what you expected VideoPro to do.

  1. Restart VideoPro. Don't worry about cleanup; the crash logs were already written when the application failed.
  2. Before doing anything else, open Help > Create Support Package. The recent crash dump is included in the package only if you collect it before the next major action overwrites the rolling logs.
  3. Save the package to a location you can find.
  4. Email the zip to support@newblueinc.com along with:
    • A description of what you were doing in the seconds before the crash.
    • Whether you can reproduce the crash on demand.
    • Whether the crash happens with a specific project or with any project.
    • Whether you've changed anything recently — new hardware, a driver update, an OS update.

If VideoPro won't start at all after the crash, see Send diagnostics to NewBlue Support — when to create the package and what to attach to your support ticket.

The package contains:

  • The application's recent logs and crash reports.
  • System information (OS version, hardware identifiers, driver versions where readable).
  • The last saved project file, without the associated content.

It does NOT contain:

  • Your other projects.
  • Your personal files.
  • Your NewBlue account password or activation key.

The support team treats the package as confidential project material. It is not shared outside the engineering and support teams.

The package carries only your last saved project file, without the associated content. When the problem involves a specific project, also send the project itself: choose File > Export. This bundles the current project with all its associated media files.

If linked video or other media makes the export too large to send, send just the project file instead — that is often enough.

If NewBlue Support asks for diagnostics, create a support package from VideoPro and attach it to your support ticket. If the issue involves a specific project, also export the project and attach that file.

Create the package as close to the problem as possible.

  • If VideoPro crashed — reopen VideoPro, then create the support package immediately before doing other work.
  • If VideoPro is behaving incorrectly but has not crashed — create the support package while the bad behavior is still happening, before closing VideoPro, restarting the computer, or changing settings.
  • If the problem is project-specific — keep the project open if you can.

The support package collects VideoPro's logs, project state, and operating-system information into a single archive that NewBlue Support can read.

See Create a Support Package for the in-app steps to create one.

If the issue happens only with a specific project, export the project and attach it with the support package. The project helps Support reproduce the issue using the same graphics, data setup, and production structure.

To export, choose File > Export Project… in VideoPro. See Save and package graphics or projects for the format options.

  1. Attach the support package to your support ticket.
  2. Attach the exported project if the issue is project-specific.
  3. If the files are too large to attach, mention that in the ticket — Support can provide an upload link.
Was this helpful?

Still need help?

Our support team is here for you.

Chat with Support800.851.4040

Related Articles

software
VideoPro — Control Your Show
software
VideoPro — Design and Customize Graphics
software
VideoPro — Get Started