Deadlock while handling callbacks

[notr1ch]

Deadlock while handling callbacks

[slidedrum]

Hello, I am not sure if I am having the exact same issue, but in the interest of not starting a duplicate issue, I think it is the same. After using this plugin, for anywhere between 5-45 minutes OBS completely locks up. It happens very frequently. It makes this plugin unuseable. The stream continues, but the scenes do not switch and I can not interact with the OBS window. I am not sure what information to give other than when it happened on stream at 40:45 https://www.twitch.tv/videos/589428140?t=0h40m45s

I am using a fresh install of OBS and Advanced Scene Switcher, the only thing I have set up is to switch the stream based on what monitor my cursor is on. https://imgur.com/SojrGX3 All other settings are default. Is there something I am doing wrong? Or is a modern update to OBS causing this plugin to break? I am using obs 25.0.4. As of writing the latest version of the software.

Thanks!

[qaptoR]

Have you checked if "Check switch conditions every Xms" makes an impact? I feel like that may change something.

UPDATE: Changing this setting to 750ms proves successful. Unable to reproduce freeze issue with rapid succession scene switches.

UPDATE: Narrowed window to 320ms and still unable to reproduce freeze. However 315ms does! Hence, ~20ms must be a sensible window to add onto the length the longest scene transition (as default fade is 300ms). Keep in mind that all systems are different and Your mileage may vary significantly.

Cheers!

[WarmUpTill]

Thanks for the report!
I havn't touched the code for a while, so I am a bit surprised about this.

Do you have more information regarding the reproduction?
Does this issue occur frequently?

[qaptoR]

Hello, I am also having the same issue as @slidedrum, I believe I've narrowed down the issue as being due to a high number of scene switches.
I have the switcher set to change display capture scenes for two monitors based on mouse location, and I can cause OBS to freeze by simply forcing constant scene changes one after the other between these two monitors.

I am also using 25.0.4. My system is fully updated as well.

UPDATE: Efforts to reproduce issue seem to reveal that high velocity scene switching causes a freeze. over 200 slow rhythmic switches proved that volume is not the determining factor. Trying to cause another switch before the previous transition finishes may be part of the problem...

UPDATE: Efforts to reproduce issue after changing scene transitions to "cut" fail, i.e. the issue seems to lie in the timing of the switches as the scene transitions fade.

UPDATE: Setting ONE monitor region scene switch to "fade" proved that fading is an issue. Eventually, after rapid velocity changes the scene refuses to switch to monitor with fade transition until a manual switch to new scene, which seems to "reset" the transition queue? (if that's a thing).
follow up rapid succession switches cause the scene to fail to switch eventually. However, it should be noted that OBS does not freeze.

SUMMARY: A temporary fix is to make all scene transitions "cut", that way there is no queue buildup that leads to a freeze.

Thank you

[slidedrum]

SUMMARY: A temporary fix is to make all scene transitions "cut", that way there is no queue buildup that leads to a freeze.

Thank you

Thanks! I will try that as a workaround for now. Fade looks nicer, but if it stops OBS from freezing, I can definitely live with a cut transition.

Have you checked if "Check switch conditions every Xms" makes an impact? I feel like that may change something.

[qaptoR]

Have you checked if "Check switch conditions every Xms" makes an impact? I feel like that may change something.

I did not know that was a setting. I will test that.

WARNING: Setting transition back to "cut" from "fade" after causing single monitor to stop transition causes the ENTIRE computer to freeze and require a reboot.
This is either because I did not manually "reset" the switching queue with a manual transition, OR because I did not restart OBS after two successive attempts to freeze the program.

[WarmUpTill]

Hi @slidedrum and @q1pt2rx,
thank very much for the detailed description of the reproduction scenario!

Because of this I think I was able to track the issue down and understand it:
The callback handler of the scene switcher for the event "OBS_FRONTEND_EVENT_SCENE_CHANGED" tries to acquire a lock which is currently being held by the main loop of the scene switcher, which itself tries to change the current scene using the "obs_frontend_set_current_scene" function.
This function call however seems to be blocked itself. (I assume until all event callback are handled)

Example:

...
SwitcherData::Thread(void) holding lock
SwitcherData::Thread(void) holding lock
SwitcherData::Thread(void) holding lock
User switched to scene 'Scene 1'
SwitcherData::Thread(void) holding lock
OBSEvent(obs_frontend_event, void *) try acquire lock

Meanwhile the callstack of the scene switcher shows it being stuck in obs_frontend_set_current_scene:

obs64.exe!OBSStudioAPI::obs_frontend_set_current_scene(obs_source * scene) Line 108 C++
obs-frontend-api.dll!obs_frontend_set_current_scene(obs_source * scene) Line 113 C++
advanced-scene-switcher.dll!switchScene(OBSRef<obs_weak_source *,&obs_weak_source_addref,&obs_weak_source_release> & scene, OBSRef<obs_weak_source *,&obs_weak_source_addref,&obs_weak_source_release> & transition, std::unique_lockstd::mutex & lock) Line 1100 C++

To resolve the problem I added an unlock of the mutex before calling obs_frontend_set_current_scene.
(I also added these unlock calls before obs_frontend_set_current_transition just in case it has a similar dependency to OBS_FRONTEND_EVENT_SCENE_CHANGED)

I attached an example build of the scene switcher for Windows 64 bit. (Assuming attaching this here works)
deadlock_fix.zip

It would be great if you could try this on your end.

Unfortunately I do not known when I will get around to building and releasing this fix.

[WarmUpTill]

I assume this is solved