Shutdown source when not visible option is not working in Studio Mode
Platform
Operating system and version: Windows 10 Pro 64bit OBS Studio version: 26.1.1 (64bit)
Expected Behavior
Unloads the page when the source is no longer visible (by clicking the eye icon to hide, or not in the active scene).
Current Behavior
The page does not unload in Studio Mode. It will get invisible but once you make it visible again the page still has it's old state.
Steps to Reproduce
- Add a Browser source that locally changes over time, such as a simple counter. I've made a simple counter here: https://codepen.io/Bob-ber/pen/WNGBRXQ . You can copy paste this in a .html file to test.
- Select "Shutdown source when not visible" in the properties of the Browser source.
- In normal mode (not Studio mode), click the eye icon to hide it and then again to make it visible and see if the page has unloaded (refreshed).
- Now do the same in Studio mode and you will see the page has not unloaded. This is the bug.
Additional information
I've tested and confirmed this. If the source is in Preview only (so it should be actually marked as not visible), hiding/showing does not properly unload the source.
I'm quite sure this is by design - Visible means visible anywhere in OBS, while Active means visible in the Program view.
This is not by design, it's definitely a bug. If you have a source that is ONLY in the Preview in Studio Mode, and you hide it, it is no longer visible anywhere. However, it does not trigger the Shutdown when not visible condition.
Any update on this bug ?
I have confirmed this is still present in OBS 32.0.1, but no further information on a solution.
This issue is not limited to the browser source, media sources suffer from the same issue.
A source that has an audio component is not immediately hidden (or set to be hidden by decrementing its active_refs counter), but instead an item_action is added to the audio_actions collection with the expectation that the audio thread will take care of the same.
The audio actions are only executed when the source volume is processed, which is triggered by different parts of the pipeline. Scenes trigger volume processing explicitly when any scene item produces audio, but transition sources don't (instead they rely on the audio thread to do this directly).
The last part is skipped if there are no "mixers" active, so what happens is:
- The top-level scene used for program output will process audio actions for its scene items
- The scene nested inside a transition for preview output will not be explicitly called by the transition to process its audio (the assumption seems to be that this is done by handling the top-level scene already), so no audio actions are processed
Because no audio actions are processed, the visibility change is never processed as well, the scene item stays "visible".
Because the program scene and preview scene are the same in "simple mode", the observed behaviour by the application is correct (as the transition's expectations are met), but in Studio Mode and with the "duplicate scene" setting enabled (which is usually desired) that connection is severed, the program scene doesn't magically "fix" the behaviour of scene items in the preview scene.
So the observed behaviour is the result of an architectural flaw in OBS Studio itself that affects all source types with an audio component used in Studio Mode with a duplicated program output scene.