Stream Backpack to StreamableRun Production Checklist: Cloud OBS, Fallback, Remote Producer, and Failure Drills

Run the backpack like a show, not a gadget test

A backpack stream fails when the team treats it as one box with one Start button. It is really a chain: camera and mic, capture and encoder, one or more uplinks, contribution transport, cloud production, platform destinations, then actual viewer playback. A clean picture on the encoder is only proof of the first few links.

This is the universal operating checklist for a LiveU Solo or Solo PRO, a BELABOX rig, or a DIY HDMI/SRT/SRTLA backpack. It does not replace the device guides. Those guides tell you how to connect a specific field kit. This one tells the team how to prepare, rehearse, call, recover, and close a real show without mixing up who owns the problem.

StreamableRun is the cloud production layer: it receives the named field ingest, gives the team Cloud Hosted OBS, scenes, fallback behavior, destinations, remote operating controls, and ingest-health visibility. The backpack, encoder vendor, SIMs, and bonding service still own field acquisition and contribution. No cloud workflow can create a camera signal after a dead battery, restore a broken HDMI lead, or force a congested tower to carry video.

• Field path: camera + microphone → capture/encoder → modems, Wi-Fi, or Ethernet → contribution transport → StreamableRun ingest.
• Production path: StreamableRun ingest → Cloud Hosted OBS scenes, audio, graphics, fallback, and recording when enabled for the account → platform destinations.
• Verification path: producer confidence view + separate viewer-side playback + moderator reports. Never use only one of those as truth.
• Secret boundary: field staff get no platform keys; producers get only the operating access they need; stream keys and ingest details stay in the dashboard or password manager, never in a group-chat screenshot.

RACI: decide who can act before something breaks

R means does the work, A means makes the live decision, C means gives input, and I means gets told. One person can hold more than one role on a small show, but name them anyway.

T-7 days: lock the architecture and prove the risky path

Do this a week out, while there is still time to replace a cable, change a data plan, or simplify a scene collection. Start with a route risk map: launch point, long walking blocks, known indoor sections, transit, venue load-in, weather exposure, and the point where the stream can end gracefully if the day turns bad.

Use the exact encoder family for the test. LiveU documents that Solo PRO bonds its available external modem, Wi-Fi, and Ethernet interfaces through its LRT service; its model and service configuration matter. BELABOX documents that its setup is only one part of a mobile rig and still needs camera, internet connections, and power. A DIY SRTLA build needs its own sender, receiver, network routing, and version match. None of those are interchangeable promises.

• Name every path: Backpack Main, Backpack Backup, Phone Backup, Main Program, BRB, Clips, Privacy, Twitch, Kick, YouTube, and Record. Delete old show names.
• Confirm the camera output matches the capture/encoder input: resolution, frame rate, connector, audio embed, and whether a camera sleep timer or auto-record setting can interrupt it.
• Choose a conservative contribution profile that survives the route. Do not pick bitrate from a home speed test. Run movement, crowd, and audio tests with the same camera, case, antennas, batteries, and pack placement.
• Inventory each uplink by carrier and physical device. Two modems on one overloaded carrier are not the same as diversity across carriers or a tested wired/Wi-Fi path.
• Confirm SIM allowance, roaming, APN requirements, carrier restrictions, country coverage, fair-use limits, and a support contact before travel. Keep account numbers out of the public runbook.
• Create the StreamableRun server, separately named ingests, Cloud Hosted OBS scene collection, destination list, and a second communication channel that does not depend on the main field phone.
• Decide whether recording is required. The current StreamableRun code gates recording to the Max plan when recording is enabled, so verify the actual account entitlement and storage/download plan before the show instead of assuming a recording exists.

T-24 hours: pack list and backpack inspection

Build the physical kit from the camera forward. Touch every connection while monitoring the image and audio. A cable that works on a desk but cuts out when the pack is zipped, the operator turns left, or a battery shifts is a failed cable for this show.

Do a power-budget rehearsal. Write each powered device, its normal draw, its likely run time, the battery that feeds it, the spare, and the safe swap point. A hot-swap is only real if the camera, encoder, modems, capture hardware, and audio chain have been tested through it. Mark batteries by state, not memory: charged, in use, depleted, and questionable.

• Physical: camera body, lens, lens cloth, media, HDMI/SDI lead, short spare lead, capture device, adapters, strain relief, encoder, antennas/modems, headphones, wired and wireless mic parts, wind protection, rain cover, and small tool kit.
• Power: encoder battery or power supply, camera batteries, modem/phone power, tested USB-C or D-Tap leads, power bank, charger, splitter only if proven under load, and a written swap order.
• Thermal and weather: leave ventilation clear, keep batteries out of direct heat where safe, pack a rain cover that does not block exhaust, and rehearse removal without yanking an antenna or HDMI cable.
• Audio: inspect lav capsule, transmitter lock, receiver battery, gain staging, camera scratch track, and headphones. Record ten seconds of speech, movement, wind, and a loud nearby sound.
• Encoder: load the correct saved profile, confirm input lock, source resolution/frame rate, audio meters, selected contribution destination, and modem/interface status. Never start from a mystery profile left over from another event.
• Credentials: confirm staff can log into the needed dashboard with their own access. Do not send platform keys, Stream IDs, secret remote URLs, or password-manager exports over chat.

T-2 hours and T-30 minutes: rehearse the entire public path

T-2 hours is a private full-path rehearsal, not a thumbnail check. Send the real backpack feed into the real StreamableRun ingest, put it through the real Cloud Hosted OBS scenes, and send it to an unlisted, private, or safe test destination where the platform supports that workflow. YouTube explicitly supports private and unlisted live settings, and asks creators to test with audio and movement similar to the actual stream.

At T-30, stop changing the architecture. Only fix a concrete failure or a safety issue. Lock the contribution profile, scene collection, destination list, and contacts. A last-minute codec, bitrate, or new browser-source experiment is an incident you scheduled yourself.

• Check latency as a chain: speak a countdown or clap on camera, compare source, Cloud OBS confidence, and viewer playback, then write down the normal delay. SRT latency is a retransmission buffer, not total glass-to-glass delay; Haivision says the higher endpoint setting is used and the buffer must be large enough for the link's loss and RTT.
• Check audio sync and clock: compare lip sync after the cloud output, verify the camera/encoder time is sensible for logs, and have producer and field operator agree on an exact call phrase and a time reference.
• Check Cloud OBS: Main, Backup, BRB/Reconnecting, Clips, Privacy, Starting, and Ending scenes all render. Fallback scenes must not carry the live field mic, private map, producer notes, or an unlicensed music source.
• Check destinations one at a time: account, title/category, key, orientation, video, program audio, delay, chat, and playback. Twitch says Inspector exposes health information from the encoder path; YouTube Live Control Room shows health messages; Kick's current help documents RTMP/RTMPS destination setup and key entry. Use each platform's own health surface as well as the StreamableRun monitor.
• Treat platform limits as final-output limits, not a reason to change a proven field contribution profile mid-show. Twitch's current health guidance says to respect its 6,000 kbps maximum; YouTube publishes codec, CBR, keyframe, resolution, and bitrate guidance by format; Kick's current destination instructions specify the RTMP/RTMPS URL and dashboard stream key. Recheck all three when you add a destination or change a show profile.
• Check recording by starting a short test, then find the finished file or documented status. A red record icon is not proof of a usable file after the show.
• Run the comms check: field operator, producer, moderator, backup operator, and channel owner each acknowledge the private channel. Keep a voice option and a text option; public chat is not emergency comms.

Go-live and during-show checklist

Start the contribution feed before you make the public program live. The producer watches the named StreamableRun ingest for stable picture, audio, and bitrate behavior, then starts the prepared program. The moderator opens viewer-side playback on the primary platform and reports only observable facts: no audio, frozen at 14:03, wrong title, or playing cleanly.

During the show, work from the outside in. Protect viewers and privacy first, then isolate the bad layer. Do not make the field operator repeatedly reboot the backpack because a destination title is wrong. Do not restart a destination because the camera cable is loose. A clear ownership boundary prevents three people from making the same outage worse.

• Before public start: main ingest present; producer on Main; fallback hot; field mic checked; primary destination preview checked; moderator playback armed; comms active.
• Every 15–30 minutes: producer checks ingest trend, Cloud OBS program audio, destination health, and available power; field operator checks cable strain, camera temperature, modem state, and battery swap timing.
• At every location transition: producer calls the next scene/fallback rule, field operator confirms motion and power plan, moderator watches for privacy or playback trouble.
• Viewer reports: moderator collects timestamp and platform. Producer compares public playback with ingest and program monitors before changing anything. One chat complaint is a signal; repeated reports plus monitoring data are evidence.
• Escalation: producer owns the public cut; field operator owns a physical recovery; technical lead owns transport/encoder escalation; channel owner decides whether to continue, reduce scope, or end.

Failure drills: make the recovery sequence muscle memory

Run these privately with a timer and a watcher. Expected automation means what the configured system may do; verify it on your own account. It never means ignore the program monitor. A drill passes only when the viewer result, communications, return-to-program check, and note are all clean.

• One modem lost — Expected automation: bonded encoder continues on remaining viable links, with capacity reduced. Field operator: confirm the affected interface and do not unplug working paths. Producer: watch contribution health, cut to BRB only if program degrades. Viewer result: program continues or sees the prepared fallback, not a mystery restart. Verify: modem returns or the remaining links sustain the chosen profile for five minutes.
• All cellular paths lost — Expected automation: contribution may reconnect when a path returns; StreamableRun fallback can preserve the produced program if configured. Field operator: move to the preplanned recovery point, check airplane mode/antenna/power only when safe, then use the designated alternate uplink or stop. Producer: immediately take BRB or Clips, keep destinations under observation, state the simple status through the moderator. Viewer result: intentional fallback or a clean planned end. Verify: source, audio, and public playback are stable before return.
• Camera failed — Expected automation: none should be assumed beyond source-loss detection. Field operator: reseat known-safe lead, change battery, or switch to prebuilt backup camera only if safe. Producer: cut away before diagnosis and select Backup only after picture and audio are confirmed. Viewer result: fallback, then a clean new shot. Verify: lens, exposure, framing, and lip sync on public playback.
• Audio failed — Expected automation: none; bad sound should not stay on program while someone debates it. Field operator: check transmitter, receiver, cable, and intended mic. Producer: mute or cut to BRB/Clips, keep fallback audio safe, then confirm meters and headphones. Viewer result: quiet intentional fallback rather than distorted or private audio. Verify: producer headphones and a viewer-side listen agree.
• Encoder or relay/contribution path failed — Expected automation: vendor-specific reconnect behavior only; do not claim LiveU, BELABOX, SRT, or SRTLA will recover every fault. Field operator: identify whether input, encoder power, uplink, or remote relay is down, then follow the approved reboot/swap path. Producer: hold fallback and prepare backup ingest. Viewer result: public program remains understandable while contribution recovers. Verify: named source returns, bitrate holds, audio is present, and no stale frame is being aired.
• StreamableRun input missing — Expected automation: the configured disconnect/fallback behavior may keep the show output alive. Field operator: confirm it is still sending to the exact named ingest; do not rotate credentials under pressure. Producer: choose fallback, check ingest selection and source status, then bring the field feed back into preview before program. Viewer result: fallback remains visible, then program returns without exposing the dashboard. Verify: ingest monitor, Cloud OBS source, and viewer playback all agree.
• Cloud OBS failed or is not controllable — Expected automation: do not assume a scene will switch itself. Field operator: keep the field source stable and wait for direction. Producer: hand control to the named backup operator, use the documented backup program path, or end destinations cleanly if no safe program control exists. Viewer result: preplanned fallback if available, otherwise an honest, controlled end rather than a looping broken image. Verify: backup operator has program control and can make a test scene change before resuming.
• Destination failed — Expected automation: other destinations may remain live, but platform sessions behave independently. Field operator: no action unless told. Producer: compare StreamableRun output with the platform health page, restart only the affected destination under the channel owner's rule, and do not disturb working outputs. Viewer result: unaffected platforms stay live; affected viewers get a short interruption or clear notice. Verify: correct platform preview, title, audio, and viewer playback after restart.
• Producer control lost — Expected automation: none. Field operator: keep the picture safe and use the agreed emergency phrase; do not reveal private locations while waiting. Backup operator: assumes producer role using least-privilege access. Moderator: posts only approved status copy and watches playback. Viewer result: stable current program or safe fallback. Verify: new producer names the active scene, source, destination state, and next action over comms.
• Power failed — Expected automation: none unless the rig was deliberately designed for it. Field operator: use the written swap order; protect camera and encoder from a brownout, then reconnect only after power is stable. Producer: go to fallback before the expected shutoff, not after. Viewer result: planned intermission instead of a dead stream. Verify: every device is powered, encoder input is locked, contribution is returning, and audio is checked before program resumes.

Incident response flow and troubleshooting matrix

Use this order under pressure: 1) protect privacy and viewer experience with a safe scene, 2) say what layer is failing, 3) assign one owner, 4) make one reversible change, 5) verify in both program and viewer playback, 6) return only when stable. Skipping directly to settings roulette creates longer outages.

• Viewer sees a frozen or black field feed: producer takes fallback → checks StreamableRun ingest → field operator checks camera/input/encoder → return after motion and audio verify.
• Viewer hears wrong, delayed, or private audio: producer mutes/cuts → field operator identifies mic versus camera scratch track → check Cloud OBS meters and public playback → return with a short spoken sync check.
• Ingest healthy but one platform is bad: leave field gear alone → producer checks platform health/key/title/output state → repair only that destination → verify its viewer page.
• No producer response: moderator calls backup operator → field operator holds safe framing or pauses contribution as previously agreed → backup announces control on private comms → verify one safe scene action.
• No safe recovery within the show's stated window: channel owner chooses a graceful end. Save timestamps, do not keep cycling power, and do not promise chat a return time nobody can support.

Post-show teardown and postmortem

Do not pack in silence and call it done. The ten minutes after a show are the best time to preserve what the next call needs: whether the fallback worked, which carrier failed, whether the public output had audio, which battery was weaker than expected, and whether a producer role was unclear.

Shut down in a controlled order: end destinations under the channel owner's plan, stop the Cloud OBS program, confirm recording completion if enabled, then stop the contribution and power down the field rig. Copy or protect any logs and recordings before temporary access disappears.

• Confirm each platform ended correctly and no destination was left accidentally live on a fallback loop.
• Check recording completion and download/access rules while the session is still easy to identify.
• Log timeline: start, first stable public playback, every cutaway, source loss, destination issue, battery swap, and end. Use timestamps, not vague memories.
• Inspect heat, moisture, bent ports, loose antennas, damaged cables, and depleted batteries before packing them with known-good spares.
• Remove temporary producer/moderator access, revoke a secret remote URL if it was shared too broadly, and rotate any platform or ingest key that left the approved secret store.
• Write three postmortem answers: what protected viewers, what took too long, and exactly what changes before the next show. Assign an owner and due date to each change.

Other resources

Use the official references below to verify vendor- and platform-specific settings before each event. Product behavior, plan access, carrier service, and destination rules can change; the operating sequence should stay stable even when a field device changes.