Showmaker needs a few one-off configurations before it is fully usable. This section covers them, both for the system administrator and for the Showmaker user.

System Administrator Only

• Follow the standard setup described in section Configuration Tool, together with the Showmaker-specific instructions, then return to this page.

Setting up Showmaker for Daily Use

Prerequisites

• Viz Mosart 5.14.3 or later.

• Manus Administrator running.

• The Viz Mosart client UI running and able to display a rundown.

Installation and Configuration

You can open a standalone, pre-production rundown in Showmaker with no additional configuration. To work with Viz Mosart templates, or to test the rundown against Viz Mosart, complete the one-off steps below.

To manage Viz Mosart templates

To work with Viz Mosart template sets in Showmaker, the bundled NRCS Plugin must be correctly configured, because Showmaker embeds it to read those template sets.

• Follow the Showmaker instructions under App Configuration.

To connect to Viz Mosart

1. Ensure your Viz Mosart system is operating under normal working conditions. As a minimum, Manus Administrator must be running, and the Viz Mosart UI must be running and displaying a rundown.

2. In the Configuration Tool, open App Configuration and confirm the required setup is complete, including the MOS communication settings that let Showmaker act as a newsroom system towards Viz Mosart.

3. Consider the scenarios under Optional Server Setups below.

4. Continue with Getting Started.

Studios

A Studio groups the MOS devices that make up one production environment, typically a main Viz Mosart server with an optional backup, or one gallery on a multi-studio site. Showmaker uses studios to decide which Viz Mosart server a rundown is sent to, and operators can override the studio on an individual rundown.

Studios are created in the MOS communication settings, and a site running several Viz Mosart back ends from one Mosart Web Apps host defines them on the Studios page. See Studios.

Show Settings

The settings that decide how a whole show behaves live on a Show settings page of their own, rather than in the Edit show dialog. Open it from the settings glyph in the top bar of the landing page, the rundown page, the rundown template page or the Show Assets page, tooltip Show settings (P), or press P.

The page is administrator only. The button is not shown to a user without the showmaker-admin role, and a non-admin who follows a direct link is returned to the show library.

There is no Save and no Cancel. Each setting is committed on its own shortly after you change it, and the top bar reports the state: Saving…, then All changes saved, which fades. If a save cannot go through you see Couldn't save changes, Fix the highlighted errors to save while a table row is invalid, or Choose a template to save while auto-select has no template picked. Leaving the page commits whatever is still outstanding, keeping the rows that are valid and reverting the ones that are not.

Leave the page with the back arrow, shortcut B, which returns you to wherever you opened it from, or the home icon, shortcut H, for the show library. If the rundown or template you came from has been deleted in the meantime, the arrow says so instead of making the trip, and offers Return to library.

What remains in Edit show: the show title, its description, Starts at and Ends at, the banner image and the studio.

Default option for new rundowns

DEFAULT OPTION FOR NEW RUNDOWNS decides what new rundowns in this show start from: Blank rundown, or Auto-select template together with a Set default template dropdown. Auto-select stays unavailable until the show has at least one template, with the tooltip Create a rundown template first, and the page offers a link to the Templates tab.

Reading-speed presets

Turn on Auto-calculate planned duration from script and the Reading-speed presets table appears. Switching the feature on for the first time seeds one usable preset, so script timing works immediately.

Each row is a Preset name, typically the presenter's name, and a Reading speed in words per minute. A radio button in the row marks the show's default.

• A show may hold at most four presets. Add preset disappears once the fourth exists.

• A name is required and must be unique within the show.

• The speed must be a whole number between 60 and 400 wpm.

• The default preset cannot be deleted; set another preset as default first. The last remaining preset cannot be deleted while the feature is on. The bin is disabled in both cases and its tooltip gives the reason.

Deleting a preset asks for confirmation, because it is not a neutral edit. The dialog names the preset and spells out the consequence: story items using it fall back to the show's default preset, and any durations calculated from script are recalculated. On a show that has somehow lost its default, it says instead that those planned durations stay as they are until a default is set.

Switching the feature off discards any preset edits made while it was on and restores the saved rows.

Story duration

AUTO-CALCULATE STORY DURATION sets each story's planned duration from the sum of its item durations. Under it, Which items count toward the total? offers All primary items or Only selected types. Choosing selected types reveals a checkbox for each primary item type and pre-ticks them all.

Story properties

A show can define its own vocabulary for its stories: a named property and the list of values a story may choose from. Journalists then pick a value per story from a dropdown instead of inventing their own wording. See Working with Showmaker for how a story uses them.

In the STORY PROPERTIES section, the count beside the heading is the number of complete definitions. Each row is a Property name and its Values (comma-separated), typed as one comma-separated list, for example Ready, In progress, Needs approval. Add property adds a row, Add first property appears while the show has none, and the bin icon removes one.

The page enforces these rules:

• A definition needs a name once it has values, and at least one value once it has a name. A row missing either is a draft: it stays on screen but is never saved.

• Names must be unique within the show, ignoring case.

• Repeated values in one list are collapsed to one.

• While any row is invalid, this section's saves are held and the top bar reads Fix the highlighted errors to save. The other sections carry on saving.

There is no limit on how many properties a show may define, nor on how many values a property may offer.

Giving a value a colour

A show-defined value can carry a colour, so a story's state reads at a glance in the story list. Per-story custom properties cannot, because the show has no vocabulary to colour them from.

A row at rest shows its values as chips rather than as text. Click a chip and a palette opens, headed Color · <value>, offering ten named colours: Red, Orange, Yellow, Teal, Mint, Indigo, Blue, Purple, Pink and Black. No color at the foot of the palette clears it. The palette is fixed and named, so a value cannot be given a shade that is illegible on a story row.

To go back to typing the values, use Edit values as text at the end of the chip row, which restores the comma-separated field. It appears only once the property has at least one value, so the first value is always typed into the field.

A colour belongs to the value's text. Change a value's spelling and it becomes a value the show has not seen before, so it starts with no colour. Remove a value and its colour goes with it.

When a property or a value is removed

Nothing is rewritten on the stories. A story keeps whatever it had chosen, but the choice stops being displayed anywhere, on the story row and in the properties panel alike, and the story list can no longer be filtered by it.

Put a value back into the definition, spelled the same way, and the stories that had it show it again. Removing the whole property is different: a property added again later is a new definition, so the old choices remain stored but are never displayed again. Renaming a value has the same effect as removing it and adding another, because a value is identified by its text.

Names shared with custom story properties

Stories can also carry their own free-form custom properties, so the two kinds can collide on a name. Showmaker flags both sides, and treats the two directions differently on purpose.

On this page, defining a property whose name the show's stories already use is allowed and shows the warning Stories already use this property name. Taking over a name journalists already type is how such a name gets promoted to the show, so it does not block the save. Be aware of the effect: every story still using its own version of that name carries two properties under one name until the custom rows are cleared.

On the story side, a custom row that takes a name the show already defines is an error, Already defined by the show. The row still saves, because the properties panel has no save button, so the message is advisory and the fix is to rename or remove the row. The check reads the show's definitions live, so adding a property to the show later flags the custom rows that were already using its name.

Matching ignores case and surrounding spaces.

Automatically delete old rundowns

AUTOMATICALLY DELETE OLD RUNDOWNS clears a show's old rundowns on a schedule, without anyone present. It is off for every show, and a show that never enables it is untouched.

Switching it on reveals:

• Delete rundowns older than a number of days, 30 by default. The server sets the permitted range and rejects anything outside it, so the field's own messages name your site's own limits rather than fixed product ones.

• Frequency, either Daily or Weekly.

• Day of week, for a weekly schedule. It is pre-filled when you switch to weekly, so the schedule is never left incomplete.

• Time of day.

The schedule is stored in UTC and shown on each viewer's own clock, so the same show reads as a different local time in another region and both are the same instant. It does not follow daylight saving: a slot set for 03:00 local drifts to 04:00 local across a transition.

A rundown's age is measured from when it was last edited, not from its air date. A rundown carrying no modification stamp falls back to when it was created. The page does not say this, so it is worth knowing before you choose a window.

What is deleted, and what is spared

Deleting a rundown takes everything attached to it: its stories and items, its comments and its change history. Viz Mosart is told to drop it as well.

Regardless of age, the purge never touches:

• rundown templates,

• a rundown that is on air at that moment,

• a rundown whose planned start is still in the future, so a show assembled well in advance is never purged before it airs,

• rundowns in any other show. The purge is scoped to the show that configured it.

Each rundown is re-checked in the instant before it is deleted, so one edited or taken on air since the pass began is skipped.

Preview before you commit

Next to the warning, Preview opens Rundowns that would be deleted. It lists the rundowns that qualify for the retention window currently on screen, oldest first, each with its air date, or No air date, and when it was last edited. It reports how many would be deleted, or No rundowns currently qualify. At most the 100 oldest are listed, noted as Showing the {n} oldest.

The preview runs exactly the same selection as the purge, so it cannot promise one set and the purge delete another.

When it runs

A background service checks once a minute and purges a show once its scheduled slot has passed. A missed slot, whether because the server was down or a pass was cut short, is caught up on the next check rather than waiting a whole period. After the API starts, the first pass is held back for two minutes so that the MOS connections are up, otherwise Viz Mosart would keep a rundown that Showmaker had deleted.

The first run does not fire immediately. Switching the purge on, or moving the schedule, records the moment as if a pass had just completed, so the first deletion waits for the next scheduled slot. Changing only the retention window deliberately does not, because that changes what qualifies rather than when the purge acts. That is what Preview is for.

At most 200 deletions are performed per minute across all shows, so a large first run drains over several minutes rather than in one burst. A show the budget did not reach stays due and continues on the next check.

Operator limits

If you need a more cautious floor than a show administrator can choose, set it on the server. These are not in the Configuration Tool: add them to the Showmaker section of the Web Apps server's appsettings.json.

There is no setting that disables the purge globally; turn it off per show. Raising the floor above a window some show already has makes the purge skip that show and log a warning once, and the show stays due until either the window or the floor is corrected.

Every pass logs what it deleted and why, naming the rundown, the show, the last-modified stamp it was judged on, the cutoff and the retention window. That log is what answers "why is this show deleting nothing?"

Roles and Access

Showmaker has two roles, which are only enforced when authentication is enabled. With authentication off, everyone has full control.

Roles are assigned in your authentication provider, not in the Configuration Tool, and are read from the roles claim. See Authentication.

Only showmaker-admin can open the Show settings page, configure the automatic deletion of old rundowns, or run its preview. The server refuses all three for a viewer, the settings button is not shown, and a direct link to the settings page returns to the show library. The keyboard shortcut list inside Showmaker, shortcut K, marks the administrator-only shortcuts, including P for Show settings.

Comments and mentions

The @mention picker is populated from the people who have signed in to Mosart Web Apps. With authentication switched off there are no identities to harvest, so the picker stays empty and mentions cannot be used. If your teams rely on mentions, enable authentication.

Video Clips

Showmaker's clip picker searches the media service on the Viz Mosart server, so:

• Media Administrator must be running on the Viz Mosart server. It performs the search.

• Current Viz Mosart servers answer clip searches over the Mosart server's own real-time connection, needing no separate key. Older versions fall back to the REST media search, which requires the Authorization Key to be set. See Server Configuration.

• How clips are labelled in the lists is controlled by the Video Clips setting. See Server Configuration.

TriCaster

Two Showmaker features use a TriCaster, and both need its address and credentials entered once under TRICASTER FOR LIVE PREVIEW. See Server Configuration.

• Uploading a clip from Showmaker to the TriCaster clip server.

• Clip thumbnails from a TriCaster, which the Mosart web server fetches on the browser's behalf so that operators need no direct access to the device and thumbnails work over HTTPS. If TriCaster clip thumbnails are blank, check the address, username and password.

To work with the Story Recorder feature

Story Recorder lets operators mark stories for recording in Viz Mosart, optionally publish the resulting clips to online platforms (TriCaster only), or replace the original story script with the recorded version. To make these controls available in Showmaker:

1. Configure Story Recorder in Viz Mosart first. See the Vizrt Documentation Center, under Viz Mosart Administrator Guide > Operational Examples > Story Recorder Setup.

2. In the Configuration Tool, open Showmaker > Feature settings and turn on Enable Story Recorder controls.

Once enabled, every story in Showmaker gains Record and Publish actions and a Use recording toggle. For how operators use these controls, see Recording a Story.

Background on Story Recorder itself is in the Vizrt Documentation Center, under Viz Mosart User Guide > Operation > Story Recorder.

Graphics Integrations

Showmaker can host graphics panels alongside the Viz Mosart templates. Both are optional and both are registered once in the Configuration Tool, under the Showmaker asset integration settings:

• Viz Pilot Edge, for editing Pilot Edge graphic templates in place.

• Viz Flowics, for cloud-based interactive HTML5 graphics. This needs an integration token issued by Flowics support. The field masks what you type, and the token is stored in the Web Apps server's configuration.

See App Configuration. Both panels are embedded in the browser and exchange MOS messages with Showmaker directly, so beyond the URL and MOS plugin ID there is no further server-side setup.

Optional Server Setups

These settings are usually performed by a system administrator.

Support for main and backup connection

• If you have a backup server for redundancy, define the environment on the Studios page, where each studio carries its own main server and optional backup.

Support for HTTPS

• If you are using HTTPS, define the environment in HTTPS and Certificates.

Troubleshooting

See section Troubleshooting.