-
-
Notifications
You must be signed in to change notification settings - Fork 730
Description
Operating System Info
Ubuntu 22.04 LTS
Other OS
No response
OBS Studio Version
29.0.x
OBS Studio Version (Other)
No response
obs-websocket Version
5.1.0
OBS Studio Log URL
N/A
OBS Studio Crash Log URL
No response
Expected Behavior
Expected Pause/Unpause to block until OBS has successfully transitioned to the paused/unpaused state.
Current Behavior
Currently, sending 'PauseRecord' will report success despite some situations in which it has not actually paused recording. This appears to be a known issue due to TODO
commends in the Record Request Handler.
// TODO: Call signal directly to perform blocking wait |
Steps to Reproduce
- PauseRecord
- ResumeRecord
- PauseRecord [<10ms later]
- ResumeRecord [ Should receive 503 RequestStatus::OutputNotPaused ]
...
Anything else we should know?
This situation is abnormal, yes. It seems ridiculous to flip paused/unpaused state so many times in 10ms, however, our usecase interprets actions and a user error triggered this edgecase.
The big problem with this bug is that OBS reports a state that it's not actually in which causes us to lose sync. We initially tried to fix this by registering a listener for 'RecordStateChanged', and blocking until we observe an event indicating the recording is paused or resumed. Unfortunately, this issue incorrectly broadcasts it's paused state, even if it's not paused.
Again, based on the code comments, this appears to be a known issue to the obs-websocket team. I wanted to file this bug to provide some info on how to trigger it, and what happens when you get into this state.