obs-websocket icon indicating copy to clipboard operation
obs-websocket copied to clipboard

Bug: Pause/Unpause race condition [mostly informational]

Open lordnynex opened this issue 4 months ago • 0 comments

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.

https://github.com/obsproject/obs-websocket/blob/40d26dbf4d29137bf88cd393a3031adb04d68bba/src/requesthandler/RequestHandler_Record.cpp#L187

Steps to Reproduce

  1. PauseRecord
  2. ResumeRecord
  3. PauseRecord [<10ms later]
  4. 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.

lordnynex avatar Sep 04 '25 17:09 lordnynex