Reliable live production under operator constraints
Stream Ops
A streaming system treated as an operations problem: reduce hidden state, reduce operator fatigue, remove brittle hops, generate assets from code where useful, and standardize the path from “going live” to “recovering when something breaks.”
obsautomationopsrunbooksstreamerbot
Problem
- Live production fails in boring ways: unreadable docks, too many middle layers, audio routing confusion, scene drift, brittle chat visibility, and operator overload at exactly the moment attention is scarce.
- A stack built from ad hoc settings can appear to work right up until a stream is live; then every hidden dependency becomes a time bomb.
Failure Analysis
- One documented failure mode was the Restream-centered path: extra hop in the signal chain, fuzzy OBS dock rendering, poor readability, and harder debugging of where the stream path was actually broken.
- Chat visibility was also a production issue, not a cosmetic one. If chat is hard to read, delayed, or scattered across windows, operator response quality falls immediately.
- This is why the repo matters: it turns “settings I clicked once” into inspectable runbooks, scripts, overlays, and repeatable artifacts.
Architecture Decisions
- Restream was removed from the critical path and replaced with direct OBS Multi-RTMP output. Fewer hops means fewer black boxes and less ambiguity when diagnosing failure.
- Streamer.bot became the consolidated operator chat surface, with platform connections pulled into one tool rather than scattered between docks and browser tabs.
- PowerToys Always On Top was used as a practical operator-control decision: boring, local, effective.
- Browser overlays were kept simple and deterministic. The starting-soon countdown computes against a fixed deadline rather than decrementing state every second, which makes it resilient to timer drift and tab scheduling jitter.
Generated Assets as Code
- This repo is stronger than a checklist because it contains generated media and utilities, not just notes. The intro bumper is produced from Python frame generation and encoded through ffmpeg, which means a visual asset is reproducible from source rather than trapped in a video editor project file.
- Notification sounds are also generated programmatically. The WAV generator builds deterministic PCM assets, including a voice-ish chat cue synthesized from partials and noise rather than imported from a random sound pack.
- That matters architecturally: brand assets become versioned artifacts, not mystery blobs.
Operating Model
- The repository separates concerns cleanly: docs for runbooks and platform notes, tools for overlays and media generation, assets for committed production resources, and exports for OBS / Streamer.bot portability.
- This is the correct shape for a live-ops repo because it lowers machine-to-machine migration cost and makes rebuilds feasible after a hardware move or OS reinstall.
- In other words, it is not “stream setup”; it is configuration management for a human-operated live system.
Result
- The end state is a more deterministic live pipeline: direct outputs, consolidated operator view, reproducible countdown/media assets, and less dependence on fuzzy UI state.
- This is my transferable engineering signal: my ability to turn a fragile, high-pressure workflow into an auditable operating system.