OBS Studio 32.2 Source Picker Upgrade Checklist for Cloud OBS Recovery

What matters in OBS Studio 32.2

OBS Studio 32.2 is not only a cosmetic update for operators. Its release notes describe an overhauled process for creating and adding sources, including a new window with preview thumbnails. That can make a busy scene collection easier to navigate, but it also changes a familiar action during the worst possible time: when somebody is trying to add or replace a source under pressure.

The practical move is to rehearse the new source workflow in a copied collection before changing a live show machine or a Cloud Hosted OBS environment. Confirm what the source picker exposes, whether existing source names still make sense, and whether a producer can find the intended camera, ingest, browser source, and fallback without relying on muscle memory from an earlier version.

StreamableRun is useful here because production can stay separated from the device that is being upgraded. Treat Cloud Hosted OBS as the program control room, give every contribution a readable name, and keep a fallback scene ready while you validate the source-picker changes.

Who needs this checklist

This checklist is for a streamer who self-produces, a remote producer who inherits a scene collection, and a technical lead who maintains templates for several shows. The more sources a show has, the more naming and selection habits matter. A field camera, backup phone, browser overlay, return feed, and media source can all look interchangeable until the wrong one is live.

It is especially useful if your current scenes grew organically. If several sources are named Video Capture Device, Browser, or Media Source, a new picker will not solve the real issue: the scene collection has no operational vocabulary. Fix that before the upgrade, while you can still compare the old and new workflows without an audience waiting.

Do not promise that every plugin or browser source behaves identically across releases. The test should identify the actual versions and sources you use. A vendor's plugin page or a single forum report can be a lead, not enough evidence to approve a production upgrade.

• Self-produced streams with more than one camera or ingest.
• Cloud OBS templates handed between producers.
• Shows using browser overlays, media sources, and remote guests.
• Teams that need a clear recovery scene during a source swap.

Clean the source inventory before upgrading

Open the active collection and make a short inventory. For each source, record the human job, actual endpoint, scene appearances, audio behavior, owner, and recovery action. Rename duplicate labels with an operator-first format such as FIELD MAIN SRT, FIELD BACKUP PHONE, PRODUCER RETURN, or FALLBACK CLIPS. Avoid names based only on how the source was originally created.

Keep destinations and credentials out of the source label. The label should help a producer make a visual choice, not expose a key or an internal route on a shared screen. Put private connection information in the service or ingest configuration and restrict access separately.

Then identify the sources that must never be accidentally deleted or replaced: the main ingest, audio bus, fallback media, technical slate, and destination output. Take an export or documented backup of the collection using your normal operational process. The goal is a recoverable configuration, not a heroic memory test.

• Name by show role, not by generic source type.
• Mark main, backup, fallback, and return paths distinctly.
• List browser-source URLs and plugin dependencies in a private runbook.
• Record which sources carry program audio and which are muted by design.

Rehearse the new picker like a producer

Use a staging scene collection and have somebody who did not build it perform a few tasks. Add a second contribution, replace a failed media source, create a browser-source copy, add a camera to a recovery scene, and remove the test source. Observe where the picker helps and where the collection's labels still create hesitation.

Preview thumbnails are helpful only when they confirm an already clear decision. They are not an excuse to rely on tiny moving pictures for routing. The operator should still know whether a source is main program, a confidence feed, a backup phone, or a browser overlay. That knowledge is what makes a handoff possible when a preview is blank.

Time the recovery drill from source failure to a stable fallback program. If the team must browse through a long unlabelled list, fix the collection rather than assuming people will be faster on show day. A safe recovery is one that a fresh producer can execute with written steps.

• Add a named test ingest without touching the program scene.
• Move to a fallback scene before simulating a replacement.
• Verify the replacement's video and audio separately.
• Ask a second operator to repeat the task from the runbook.

Browser sources, plugins, and local files

Source-creation changes are a good time to audit browser sources and plugins, not a reason to assume they broke. Browser sources often carry alerts, chat, maps, scoreboards, and remote controls. A blank browser layer may come from authentication, cache, permissions, a network dependency, or the page itself rather than the OBS upgrade.

Test every show-critical browser layer with its real resolution, audio setting, and scene visibility behavior. Refreshing a page can be a recovery step, but it should not be the first guess. Confirm that the source has a stable URL, that any required login is handled safely, and that the fallback scene remains useful when the layer is absent.

For plugins, consult the maintainer's compatibility statement and test the exact build in staging. Keep plugin updates separate from a major OBS workflow change when possible. If a plugin is vital but compatibility is uncertain, the responsible choice is to defer the OBS change for that production path.

Cloud OBS scene design that survives a source swap

Build Cloud Hosted OBS scenes around decisions rather than hardware. A main scene should contain the current contribution and the stable overlays. A backup scene should use a separate ingest. A fallback scene should include a clean message, safe audio, and clips or media that can run while the source is repaired. A technical scene can be private or public depending on the show plan, but its role must be explicit.

Keep each scene's source visibility deliberate. Do not leave a backup audio source live beneath the main camera just because it is convenient. During rehearsal, mute or disable the main source, take fallback, bring up the backup, and confirm that the change did not create doubled audio, stale overlays, or a black browser layer.

This is where Cloud Hosted OBS is a practical control plane. The field device can restart, a producer can replace a contribution, and the public program can stay on a known scene while the team confirms the new source. The scene collection should make that separation obvious.

• Main: current contribution plus only needed overlays.
• Backup: independently testable source and audio path.
• Fallback: viewer-safe message, clips, or BRB content.
• Technical: clear diagnostics without exposing secrets publicly.

Destination and monitoring checks

A local preview is not enough after a source change. Verify the StreamableRun ingest, Cloud OBS program, destination connection, and viewer-facing platform preview. A source may look fine in OBS while the final destination shows a codec warning, delayed audio, or a frozen segment caused by the upstream route.

Keep destinations managed in the cloud workflow so the producer does not copy keys into a rushed source replacement. For Twitch, Kick, YouTube, or custom RTMP outputs, confirm the normal output profile and test the fallback scene at the real destination. A temporary test key is fine when available, but it should behave like the production path.

For handoff, the outgoing operator should state which source is live, whether the backup is warm, what scene the producer should take on failure, and who owns the source repair. That is enough information to keep decisions fast without asking one person to explain the whole collection on a call.

Upgrade decision and resources

Move OBS 32.2 into the live template only when the inventory, source-picker rehearsal, browser-source check, failure drill, destination check, and handoff all pass. If source selection becomes easier but a required plugin is unclear, keep the stable production version and revisit when the plugin maintainer documents support.

The quality bar is simple: a producer should be able to identify the right source, preserve program audio, use fallback, and verify a destination without improvising. The version number is not the win. A scene collection that survives a source failure is.