> For the complete documentation index, see [llms.txt](https://captivatehelp.newbluelive.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://captivatehelp.newbluelive.com/troubleshooting/read-the-message-log.md). # Read the Message Log The Message Log is a dock panel in Captivate 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 the panel Open **View > Message Log**. The dock appears tabified with Properties and (on Captivate 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. Captivate 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). ## What the action names mean 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. ## Reading a problem 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. ## Auto Scroll and Clear Log 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. ## Record a session for support 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**. Captivate 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](/troubleshooting/report-a-problem-with-a-support-package.md) for the full procedure. The Message Log records what Captivate did; the Support Package records what Captivate 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](/troubleshooting/send-a-diagnostic-report.md). ## Related * [Playback doesn’t behave as expected](/troubleshooting/playback-doesnt-behave-as-expected.md) * [Create a Support Package](/troubleshooting/report-a-problem-with-a-support-package.md) * [Send diagnostics to NewBlue Support](/troubleshooting/send-a-diagnostic-report.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://captivatehelp.newbluelive.com/troubleshooting/read-the-message-log.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.