Why Your Paid Alert Queue Forgets Itself When You Switch OBS Scenes

Three words that sound alike: visible, active, unloaded

Picture a streamer mid-show. A viewer pays for a long TTS read, it starts, and she hits her BRB hotkey to swap scenes. When she comes back, the line starts over from the top. Or it never comes back at all. Or the next three queued items fire at once.

OBS gives you separate ideas to reason about. A source is visible or hidden, which is the eye icon in the sources list. A source is active or inactive, which tracks whether its scene is the one being shown. And a page can be loaded or unloaded, meaning the browser content is running or has been torn down. The obs-browser plugin exposes the first two to your page as separate events, obsSourceVisibleChanged and obsSourceActiveChanged. The third one is the one that hurts, because an unloaded page has no memory of what it was doing.

What the docs say, and what they leave out

The OBS knowledge base page for Browser Source lists the two properties that matter here. Shutdown source when not visible unloads the page when the source is no longer visible, either because you clicked the eye icon or because it is not in the active scene. Its default is Off. Refresh browser source when scene becomes active refreshes the page when its scene is switched to. Its default is also Off. So by the docs, a default source keeps running through scene changes.

The obs-browser README adds the scripting side. It documents a window.obsstudio object, a list of events your page can listen for that includes both obsSourceVisibleChanged and obsSourceActiveChanged, and the older onVisibilityChange and onActiveChange callbacks, which are marked legacy and pass a plain true or false. The README does not walk through the payload of the newer events in its short event list, so log event.detail once in your own OBS build and read the field names off the console before you write code that depends on them.

Here is what neither page says. Neither describes what happens to audio that is playing at the moment a page unloads. Neither says whether your page gets a last chance to save state before it goes. Neither promises that a page with both boxes unchecked will never lose state. Treat all three as questions for your own test. A forum thread from a user on OBS 27 even reports a chat widget losing its contents on scene changes with both boxes unchecked; that is one user, unresolved in the thread, but it is why I would not trust the defaults blindly.

Shutdown when hidden and a queue that lives in the page

The shutdown checkbox suits a decorative overlay. It is a risky choice for any page that is the only holder of live queue state.

Think about what a typical alert page does. It connects, receives events, puts them in an array, plays the first one, waits for it to finish, and moves to the next. If that array lives only inside the page, then unloading the page empties the array. The viewer who paid is not in it anymore. Nothing errored. The item just evaporated, or the sender redelivers it because it never saw an acknowledgement.

Redelivery is why this shows up as replay and not only as loss. If the sender keeps an item pending until the page confirms it played, a fresh load can receive the item again. Whether your tool does that is for its owner to say.

On audio, one forum thread about OBS 31.0.2 has a user saying a source set to disable when not showing kept playing audio after a scene change, tied to a hidden transition. That is a single report I did not see confirmed, so test your own version.

Refresh on active: the replay hazard

The refresh checkbox solves a real problem: a stale page gets a clean reload every time you return to the scene. For a stats panel, great.

For a paid queue it can be a trap, because every return is a full page load. If the page asks the server what is pending, and the mid-play item was not marked finished, the reload plays it again. If the server only pushes new events, the reload silently skips it. Opposite bugs, same unhappy viewer.

Picture a streamer who flips between Game and Chatting four times in ten minutes. With refresh on, that is four page loads, and each could replay one in-flight item.

So do not use refresh on active as a general fix for stale pages until you have tested what a reload does to a half-played item. For a deliberate reset between segments, the KB's Refresh cache of current page button, which it says immediately refreshes the page and reloads content, is easier to control.

A scene-transition test grid

Use a test event, never a real paid one. Start a long TTS read or a slow-fading upload card, switch scenes mid-play, wait ten seconds, switch back, and fill in each row below.

Rows are settings. Columns, for every row: did the item resume, restart, finish silently or disappear; did audio stop, finish the line or carry on; did the queue behind it keep its order; did anything play twice.

• Row A, both boxes Off (the documented defaults): switch away and back. Watch whether the page kept running, and whether you hear its audio while its scene is off screen.
• Row B, shutdown On, refresh Off: switch away mid-play and wait. Watch for the cut-off point of the audio, what returns on re-entry, and whether the queue behind the item is intact.
• Row C, shutdown Off, refresh On: switch away and back. Watch for a restart of the in-flight item, a duplicate of an item already finished, and a skipped one.
• Row D, both On: the harshest case. Watch for a full unload and reload, and compare what the server thinks is pending against the screen.
• Extra pass: toggle the eye icon instead of changing scenes. The KB lists both as shutdown triggers, but the events are distinct, so confirm they behave alike.
• Extra pass: repeat in Studio Mode with your live transition. A user report on the obs-browser tracker, filed against OBS 27.0.1, says a hidden source may pause processing unless Studio Mode, a multiview or a projector shows it. That is not documented behavior and the version is old, so find out what your install does.

Where queue state should live

The clean answer is easy to state and harder to build: the page is a display, and the queue lives elsewhere. A server-side record of what is pending, approved, playing and finished survives the page disappearing. The page asks what to show, shows it, and reports back when it is done.

Four properties help. An item counts as played only after the page confirms it. A reload resumes or restarts the current item by a rule you picked. Items carry stable IDs so a page can drop a duplicate. And the moderator view reads the same record, so the mod sees what the page shows.

This is a pattern, not a claim that any particular tool does it. Ask your alert supplier how the page behaves on reload, then run Rows B and C to check the answer. If nobody can say, assume the page is the memory and leave both lifecycle boxes Off.

The question that matters most for uploads: once a mod has approved one, what happens to it if the page reloads before it airs? If your tool cannot answer that, treat approved-but-unplayed as a state you check by hand after every scene hiccup.

Defaults that get blamed on the lifecycle

Some scene-change weirdness is really a default. The KB lists a viewport of 800 wide by 600 high. If your layout assumes another size and you stretched the source in the scene instead of setting width and height in its properties, a fresh load can look cropped or scaled differently than the one you tuned by eye.

Custom frame rate is Off by default, and the FPS value is 30 when you turn it on, so fast motion can look choppier than you assumed.

The default custom CSS sets a transparent background, zero margins on the body and hides overflow. Because overflow is hidden, a card that animates in from outside the box gets clipped.

If only the look changes after a reload, suspect a default first.

Page permissions for pages you do not control

The KB says Page permissions let the browser read and or modify OBS options, with read access to OBS status information shown as the entry. The README gives the scale: 0 none, 1 read OBS data, 2 read user data, 3 basic, 4 advanced, 5 all, with each API call tagged by the level it needs.

Why raise it here? People bump the level while debugging a scene problem and forget to lower it. The README tags start and stop streaming as needing level 5, and an alert overlay should never hold that.

Keep it at the lowest level that works, and confirm in a test which level your page needs instead of assuming. Be strict with any URL you did not write yourself.

A pre-stream drill and what to tell mods

Before going live, run a drill with a private test event. Start a long item, switch scenes with the exact hotkey or deck button you use on stream, wait, come back, and write down what happened to the item, the audio and the queue behind it.

Then decide a policy for the half-played item and put it in the mod notes, because someone will have to apply it live. Pick one: replay it from the start, skip it and make it right with the viewer, or let it finish on the next scene. A short TTS tip might replay without anyone caring; a paid upload shown twice may not be fine.

• Tell mods which scenes are safe to switch from mid-item, and which are not.
• Give them one reset step: for example, the Refresh cache button, used only between items.
• Show them what a duplicate looks like, and who removes it.
• Agree on what to say in chat when an item restarts, so viewers who paid are not left guessing.
• Note the OBS version and both checkbox states, since an update may change your grid.