The show page tells you what the seat is. This tells you how to run it. Read it end to end once; after that it is a reference you come back to under time pressure, which is why every section is short and every rule says why it exists.

AThe rig — encoder and output

Settings that are wrong here fail quietly: the stream goes out, looks acceptable to you, and degrades for everyone watching on a worse connection than yours.

BThe audio chain

Audio is what makes a stream feel amateur, and it is the thing viewers leave over. Gain-stage before you filter anything. Raw microphone peaks belong at −12 to −6 dB. Filters applied to a signal that is too quiet just amplify the room.

That order is not a preference. OBS runs filters top to bottom. Clean the signal, then shape it, then protect it. Compress before you suppress and you have amplified the noise floor into the same range as the voice, where suppression can no longer separate them.

CCameras and inputs

Participants bring a computer and a phone. The phone is the second angle, and it is usually the better sensor — a modern rear camera beats almost any webcam.

• Rear lens, never the selfie camera. Bigger sensor, better in poor light.
• Choose the smooth/low-latency profile over maximum resolution. On a live show, delay costs more than sharpness.
• Set 1920×1080 in two places — the source itself and the OBS browser source. Setting one and not the other silently gives you an upscaled 720p.
• Lock the camera down: manual focus (auto-focus hunts every time hands move), shutter at double the frame rate, lowest usable ISO, and a fixed white balance matched to the room. Auto-anything drifts on camera.
• Sync offset. USB and browser video arrive late; microphone audio does not. Expect to delay audio by 100–300 ms (200 is a good first try) and confirm with a clap.
• Phones get hot and phones are needed. A handset running a camera feed for two hours is hot enough to matter, and it is also the device that person takes calls on. Treat it as a second angle, not the primary.

DGuests

Every participant is a remote guest, so this is the section you will use most. Guests join a room in the browser; you take each one into OBS as a source.

1. Create the room as director. Keep the invite link and the per-guest view links separate — you send the first, you paste the second.
2. Add each guest to OBS as a browser source at 1920×1080.
3. Tick "control audio via OBS" on every one. Without it the audio bypasses your mixer entirely and you have no fader on a live person.
4. Send your programme output back into the room as a virtual camera. Guests then see what is actually on air — a real tally light, and they stop asking whether they are live.

Echo — the one you will fight every week

Echo is caused by speakers, essentially always. A guest on speakers has your voice coming out beside their microphone, which sends it back to you. There is no software fix that beats the physical one.

• Headphones are required, not encouraged. Any wired pair works; the cheapest wired earbuds solve this completely. See the setup sheets for what we tell them to buy.
• Echo cancellation on only for someone who genuinely cannot wear headphones — it degrades their voice, so it is the fallback, not the default.
• Wired network over wireless wherever it is possible at all.
• Mute anyone not speaking. Desk knocks and chairs are picked up long before anyone notices they are transmitting.

EScenes and graphics

Sixty-five episodes means the layout gets built once and reused. Build it so a change happens in one place.

• One source scene per feed, nested into every layout. A colour correction or a resolution fix then applies everywhere at once. Duplicating a camera into six scenes guarantees six versions that slowly stop matching.
• When one feed genuinely needs different treatment in different layouts, clone the source rather than rebuilding it.
• Animated assets are media sources with loop enabled; static ones are images. Picking the wrong type is why an overlay "will not import".
• Data-driven graphics — scores, names, tickers, gate verdicts — are HTML browser sources that read the system's own state and re-render in place. They are version-controlled and styled from brand tokens, and they need no plugin and no second machine. You do not type into them.
• NDI is local-network only and is relevant only if a real-time 3D engine is adopted, which is still an open decision — see the architecture page. If it is adopted, the plugin has to be installed and OBS restarted before the source type appears. Until then there is nothing to install.
• Lock every layer before you go live. The most common self-inflicted on-air fault is dragging a source while reaching for something else.

FRecording while streaming

The live stream is not the deliverable. The recording is, because it becomes the episode, the clips and the archive.

• Record each source separately as well as the programme mix. A clean camera with no overlays burned in is what makes a good clip later; a composited recording is stuck the way it aired.
• Separate audio tracks per person. One person coughing over the answer is fixable on separate tracks and permanent on a mixed one.
• If vertical cuts are wanted, produce them in the same session rather than re-cropping later.

GSimulcast — the destinations

Every episode goes to all of them, horizontal and vertical at once. Each destination is there for a different reason, and the reason drives what you do with the feed.

HPre-flight — the stream does not start until this passes

1. Test broadcast, 60–120 seconds, to the real destination. Confirms ingest and that your bitrate survives your actual upload right now.
2. Test recording, 20–30 seconds — and play it back. Recording it is not the test. Watching it is.
3. Clap on camera and check the sound lands on the frame where hands meet. If not, set the sync offset now.
4. Stats panel: no encoding overload, no missed frames, no dropped frames. All three are zero, not "low".
5. Every participant confirmed — camera up, level in range, headphones on, name correct on screen.
6. Release status verified for everyone on camera today. Unsigned means not on the stream. This is the one item with no discretion attached to it.

IWhen it breaks live

It will. What is being judged is not whether something broke, it is how long the audience watched it break.

JElimination night

Every fourth Saturday, and it is a different programme from a weekday episode. Somebody is losing a job on camera.

• Nothing about the outcome is improvised. The decision is read from the system — work executed, gates passed, work published. Your job is to make sure it is legible on screen.
• Each participant's counterpart speaks about them on air. Build a layout that holds both faces; this is the moment the audience is actually watching.
• Record everything separately. This is the most-clipped night of the cycle and clips need clean sources.
• Have the exit handled before you go live — access, the closing shot, and what airs after. Discovering it live is a bad look at somebody else's expense.

The run of show, the rounds and the dates are on the programme page. They are not repeated here on purpose — two copies of a schedule become two different schedules.

KAfter the stream

1. Remux if needed, and confirm the file plays before you close anything.
2. Check the per-source recordings exist and are not zero-length. This is the failure people find a week later.
3. Hand off to the Technical Operator in the agreed format and location.
4. File the incident log, including a clean night with nothing on it — "nothing went wrong" is data.

LEscalation — who decides what

You produce. You do not approve. The Executive Manager holds the brand sign-off; the Executive Chairman holds the show sign-off. Neither of those is yours, and neither should be discovered mid-season.

Companion sheets: what participants set up on their own machines · the programme and the itinerary.