4. System Admins and Test Mode

Contents

System Admins vs Client Admins
Impersonation
Managing Stream Keys
Test Events
Pre-Event Testing and Test Broadcasts
Invitations and Duplicate Emails
OBS Test Clock

System Admins vs Client Admins

A system admin has cross-Client access to the whole platform (every Client’s events, settings, and
the System Administration section itself), separate from and in addition to any Client-level role.
System admins are managed from their own admin page.

Permissions are tiered: Readonly < User < Client Admin < system admin. Each tier can do
everything the one below it can, and a system admin passes every tier’s check. For the full
per-role breakdown see
What Each Role Can Actually Do.

Actions Only System Admins Can Take

• Changing an event’s Timezone.
• Adding, editing, enabling, disabling, rotating and deleting stream keys (see
  Managing Stream Keys).
• Unconfiguring (deleting) a test event.

Client members see these controls disabled with ”🔒 Set by system administrators”.

System admins also bypass two policies: Stream Preview being off (they can always watch the live
preview) and the signage setup-day window. They do not bypass Keyframe Interval Check being
off, or the state locks that protect a running event — the stream key, timezone and channel locks
apply to system admins too. For example, the timezone is refused with “Broadcast days from today on
(dates) are dates in this timezone. Remove them to change the timezone.”

Impersonation

A system admin can impersonate a Client to see the platform exactly as that Client would. An
impersonation session is time-limited and clearly marked as impersonation — it isn’t a way to
permanently act as another account.

Starting an impersonation takes you to that member’s dashboard, and Exit Impersonation in the
banner brings you back to the Clients page. Each switch reloads everything on screen, so what you
see is always the data of the account you’re acting as, never leftovers from the one before. While
impersonating you see what the member sees: their role’s dimmed controls, the plain-language clip
and upload reasons instead of raw errors (see
What Clients Don’t See),
and the match list for the events their Client can read.

Managing Stream Keys

Creating, renaming, enabling/disabling, rotating and deleting stream keys is system-admin-only.
Reveal/Copy is available to User and above; every client role sees Add, Disable,
Rotate and Delete disabled with the 🔒 reason (see
Stream Keys and Restream Keys). To manage a Client’s stream keys:

1. Open Clients in the admin section and click into the Client you need.
2. In its Stream Keys section, click + Add Key, enter a Key label (e.g. “Field 1
   Camera”), and click Create Key. The stream key value itself is generated automatically —
   there’s no field to type or paste one in.
3. To see or copy a key’s value here, use Reveal/Copy the same way a Client Admin would —
   Copy sits next to the masked value and is available as soon as Reveal is, without having to
   reveal the key on screen first.
4. To stop a key from being accepted without deleting it, click Disable (and Enable to turn
   it back on) — this is the right choice for a key you might reuse later, or while you sort out a
   compromised key without losing its history.
5. To replace a key’s value in place without touching its id, label, active flag, or event
   assignments, click Rotate on the key’s row. (It’s also on the client dashboard’s Stream
   Keys page, which lists every Client’s keys when you’re signed in as a system admin and not
   impersonating — an impersonation session has the member’s role, not yours.) Confirmation:
   “Rotate key “{label}”? The old value will stop working immediately, any encoder or event still
   using it will need to be updated with the new value, and any session currently live on this key
   will be ended.” Confirming ends any session currently live on the old value and disconnects that
   encoder; the new value is revealed once so you can copy it before it’s masked again. Rotation
   itself always succeeds even if the platform can’t reach the streaming server to end that session
   — in that rare case the audit log gets an extra rotate_kick_failed entry reading: “RTMP kick
   failed after rotation — MediaMTX unreachable; the old stream key may still be publishing until
   the encoder reconnects or the orphan sweep catches it.” If you see that entry, have the operator
   stop and restart their encoder with the new key rather than assuming the old session ended on its
   own.
6. To permanently remove a key, click Delete. Confirmation: “Delete key “{label}”? This cannot
   be undone.” If any scheduled event still references the key, the delete is rejected with “Cannot
   delete: {n} event(s) use this key. Disable it instead to prevent new streams.” — reassign or
   disable first if you actually need it gone.

Both a stream key rotation and a restream key rotation (see
Stream Keys and Restream Keys)
are recorded in the audit log as “rotate” (plus the rotate_kick_failed entry above when a stream
key rotation couldn’t end the old session).

Changing an Event’s Stream Key

An event’s stream key can’t be changed:

• while the stream is live — “The stream is live (video is coming in on this event’s stream key).
  Stop streaming to change the stream key.”;
• while the restream push is running — “The restream push is running. Stop the push to change the
  stream key.”;
• once clips exist — “Stream key cannot be changed after clips have been recorded”.

These locks apply to system admins too. Changing the key doesn’t break the event’s YouTube
restream, because a push finds its destination through today’s broadcast rather than the stream
key. Moving an event onto a stream key that belongs to a different Client moves the event to that
Client.

Test Events

Test events let you rehearse the full pipeline without waiting for a real match schedule, using a
re-anchored schedule so the pipeline behaves as if matches were actually happening. By default a
test match runs 90 seconds, with a 10-second dwell time between a match’s end and its score being
posted, 8 minutes between match starts, and a 60-second delay before the first simulated match
starts — all configurable under
System Settings Reference.

The test_mode_upload_enabled and test_mode_restream_enabled settings apply only to events marked
as test events. They’re in the Test Event Uploads & Re-Streaming section at the top of the
Settings page’s Test Mode tab (Test Mode Uploads and Test Mode Re-Streaming), and both
are off by default:

• test_mode_upload_enabled gates test-event uploads, so a fresh test event won’t send anything to
  YouTube until it’s turned on deliberately.
• test_mode_restream_enabled gates manual-key test events only. A test event in YouTube-channel
  mode restreams whenever restreaming is enabled.

A few other things differ from a real event: a test event’s stream window is locked (“A test event
keeps its test-mode stream window”), and only a system admin can unconfigure (delete) one.

Creating a Test Event

The Test Mode create form has:

• Client — a selector defaulting to System. Leave it on System to create a private test event
  only system admins see, the same as before. Choose a real Client to create the test event on their
  behalf instead.
• Stream Key — only shown once you’ve chosen a non-System Client, defaulting to “(client’s
  first active key)”. Pick a different key from that Client if you want the test on a specific one.

The Test Events table has a Client column so you can tell at a glance which Client (or System)
each test event belongs to.

A test event created on a real Client appears in that Client’s own Events list with a yellow TEST
badge, and behaves like any other configured event for status, control center, match list, clips,
and uploads —
subject to the same test_mode_upload_enabled/test_mode_restream_enabled gates described above.
Client members can see it and adjust its configuration from Event Configuration just like a real
event, but can’t create or delete it themselves — only a system admin can. A new test event starts
with no YouTube channel, restream key, or signage assigned; configure those from Event Configuration
the same way you would for any other event.

How Test Matches Are Scheduled

• A test event (code TEST-n) spans the creator’s local day and has 10 pre-generated matches.
  Their provisional times come from Cycle Time (minutes between match starts) and Match
  Length.
• A real stream must be coming in on the event’s stream key. When recording starts, the schedule is
  re-anchored: match 1 is at the later of the recording start and the event’s start, plus
  First Match Delay, and each later match starts one cycle time after the previous one. The
  event’s end time is extended to cover the last clip.
• The anchor is kept, so a reconnect in the middle of the test doesn’t rewind or restart the
  matches.
• A match counts as done at its scheduled time + match length + Dwell Time. Dwell is the gap
  between a match’s end and its score being posted, not the gap between matches. When a match
  is done it gets random final scores, and a clip is queued from its start minus the padding-before
  to its done time plus the padding-after.
• Creating a test event is refused unless match length + dwell time fits within the cycle time:
  “match_length (Ns) + dwell_time (Ns) must be ≤ cycle_time (Ns)”.
• Uploads: test clips upload only when test_mode_upload_enabled is on and Operation Mode
  isn’t Record Only. They always upload unlisted, with no playlists. An admin force-release
  from the Jobs page skips the test gate.
• Restreaming: see test_mode_restream_enabled above.

Pre-Event Testing and Test Broadcasts

Encoders can publish to an event from one day before its start time. While they do, the event shows
“Pre-event test”. A pre-event test doesn’t restream, and Start Push is refused until the start
time, with one exception: on the day before the event, an event with a setup-day test video
pushes its test feed to that unlisted video (see
The Setup-Day Test Video).
At the start time the event becomes live without the encoder having
to reconnect. Client Admins and system admins can move the event’s stream window by up to 7
days either way — see
Event Configuration Reference.

Running a Test Broadcast

YouTube can report a stream as healthy and still not play it, and nothing in the platform checks
audio. Before an important event — and after any platform release that touches restreaming — run a
test broadcast:

1. Create a test event, or use a private Client event, with an unlisted YouTube broadcast.
2. Stream to it from OBS, then Start Push.
3. Go Live.
4. On YouTube, confirm that both audio and video play.
5. Stop Broadcast, then Stop Push.

For a real event, the setup-day test video does the same job on the day before, on the event’s own
stream key and channel. With YouTube Preview (Monitor Stream) on, also check the preview in
YouTube Studio between steps 2 and 3: it should come up by itself once the push is running.

See YouTube Broadcasts for the
operator side of broadcasts.

Invitations and Duplicate Emails

Invite links expire after 7 days, and an expired invite can’t be claimed. The member shows an
“Invite expired” badge in the Members list, on both the admin Client page and the Client’s own
Members page; click Re-send invite on their row for a new link (see
Members and Roles).
The last-admin rules there don’t bind system admins: you can disable, delete or demote a Client’s
last active Client Admin, so make sure the Client has another one first.

Duplicate emails are refused: “A member with this email already exists” for a Client member, and
“An admin with that email already exists” for a system admin. Emails are compared without regard to
case. The database migration that enforces this stops if existing members have emails that differ
only in case; that’s covered in the kube-match-splitter repository’s DEPLOYMENT.md, for people
with repository access.

OBS Test Clock

A browser-source page provided by the platform (/api/obs/clock, unauthenticated by design so it
can be added as an OBS browser source without a login) shows a calibration clock operators can use
to check stream timing, delay and audio before a real event starts. The full URL is shown, with a
Copy button, under OBS Test Clock URL on the Test Mode tab of System Settings. Treat this as
an advanced, optional tool rather than something every event needs.

Adding It to OBS

1. Add a Browser Source with the clock URL, sized to the canvas.
2. Tick Control audio via OBS so the beeps and tones reach the stream.

The page has no controls. Its settings are read when the page loads, so after changing them,
right-click the source and choose Refresh cache of current page. The page is cached for about 5
seconds and never polls. The browser may keep audio muted until the page has been interacted with,
so beeps can stay silent.

What the Page Shows

• A millisecond clock and motion indicators: a bouncing dot, a spinner, a progress bar, a frame
  counter, FPS, uptime, and clock skew against the server.
• Optional SMPTE color bars and audio tones.
• A footer using the Signage Idle Footer Text setting.

Display Settings

Set on the Test Mode tab of
System Settings Reference:

Setting	Default
12-Hour Clock	off (24-hour)
Timezone	UTC
Show Color Bars	on
Show Diagnostics Row	on
Beep Interval (s)	10 (0 = off)
Top-of-Minute Chime	on
440Hz Reference Tone	off
Audio Channel	both (or left/right)
Volume (%)	20

Per-Load URL Overrides

Add query parameters to the clock URL to override some settings for that page load only, for
example /api/obs/clock?hour12=1&tz=America/New_York&bars=0:

Parameter	Values	Overrides
hour12	1 / 0	12-Hour Clock
tz	an IANA time zone name	Timezone
bars	1 / 0	Show Color Bars
beep	seconds, 0–3600	Beep Interval (s)
volume	0–100	Volume (%)

Overrides aren’t saved. An invalid or out-of-range value is ignored and the saved setting is used
instead (it isn’t clamped). Diagnostics, the chime, the reference tone and the audio channel have
no URL parameter.