Cannnot subscribe to event ,After Request ToggleRecord.

[Parfaitomcat]

While creating a simple program, I found something that seemed to be a problem and reported it. The issue is that the program cannnot subscribe to events after requesting a toggle record.

The code for the simplified program is below.

public class TestProgram { ObsClient client; public static void main( ) { client= new ObsClient ( ) bool _isConnect = await client.ConnectAsync(password,host,port, EventSubscriptions.All) switch(_isConnect) { case true: cient.RecordStateChanged += ObsClient_RecordStateChanged; client.StreamStateChanged += ObsClient_StreamStateChanged; break; case false break;
} Console.readLine(); // When the OBS record or/and stream buttons are pressed, the occurrence of the event will be displayed on the command line.

     Console.readLine();
     client.ToggleStream();
   //  When the OBS record or/and stream buttons are pressed, the occurrence of the event will be displayed on the command line.
    Console.readLine()
    client.ToggleRecord()
  // When the OBS record button and broadcast button are pressed, the event occurrence **### is not** displayed on the command line
    Console.readLine()
  }
    private Task ObsClient_StreamStateChanged(object? sender, OBSStudioClient.Events.OutputStateChangedEventArgs e)
    {
        IsStream = e.OutputActive;
        Console.WriteLine(e.OutputState);
        StreamingStatus = OutputEunm2String(e.OutputState);
        return Task.CompletedTask;
    }
    private Task ObsClient_RecordStateChanged(object? sender, OBSStudioClient.Events.RecordStateChangedEventArgs e)
    {
        IsRecord = e.OutputActive;
        Console.WriteLine(e.OutputState);
        RecordingStatus = OutputEunm2String(e.OutputState);
        return Task.CompletedTask;
    }

}

The above is a modified version of the distributed sample program, and similar results were confirmed when experimenting.

[Parfaitomcat]

I compared the three types of code: outputs request, stream request, and record stream based on what I know. As a result, we discovered questions about the current code in at least two places.

The first is Located in the RequestResponseMessage.cs file.

Line 215 Currently RequestType.ToggleRecord => null,

Correction RequestType.ToggleRecord => this.RawResponseData.Value.Deserialize(),

Line 218 Currently RequestType.ToggleRecordPause => null,

Correction RequestType.ToggleRecordPause => > this.RawResponseData.Value.Deserialize() I think it is necessary to change to.

The Second is Located in the obsClient_RecordRequests.cs file Line 19-22 Carrent public async Task ToggleRecord() { await this.SendRequestAsync(); } Correction public async Task ToggleRecord() { return (await this.SendRequestAsync()).OutputActive; }

Line 36-39 Carrent public async Task StopRecord() { return (await this.SendRequestAsync()).OutputPath; } Correction public async Task StopRecord() { await this.SendRequestAsync(); }

Line 44-47 Carrent public async Task ToggleRecordPause() { await this.SendRequestAsync(); }

Correction public async Task ToggleRecordPause() { return (await this.SendRequestAsync()).OutputPaused; }

[tinodo]

The calls ToggleRecordPause and ToggleRecord to OBS Studio should not provide any response, according to the protocol specification. Hence, the calls in the client return no value. To capture the state of the recording, you should use the events like RecordStateChanged. The StopRecord message already return the OutputPath, which is correct according to the protocol specification.

If you want to change that behavior, you can override the methods provided. But I think at this point, the client is doing what is specified on the protocol.

Can you clarify on why you'd like a different behavior?

[Parfaitomcat]

I made sure you were designing according to the protocol. I didn't check the protocol, so I misunderstood that toggle streams and toggle records behave similarly. I apologize for this point. On the other hand, what I essentially want to report is the resolution of the problem that if I use the toggle record method, an event occurs in which the subscribed event can no longer be subscribed. I ask you to confirm that my report is correct in the Sample Windows Application. If possible, I'd like you to update the Sample Windows Application and add sample code for toggle records.

[tinodo]

Thanks for the feedback @Parfaitomcat !

Indeed, the calls ToggleRecord and ToggleRecordPause do return a value, although the protocol specification clearly states otherwise. I have modified the behavior of the calls in v1.3.0; they now both return a bool. I have checked in the code into the repo, and I will create a new package shortly. Also, the sample client has been updated with some buttons to do all the "Record" operations.

The new package also adds support for a 5.3.0 call.

I'm not sure if you're using the source code or the package, but let me know if this worked for you!

[tinodo]

Version 1.3.0 is now available as a package from NuGet and from GitHub.

Let me know how this works for you!

[Parfaitomcat]

Thank you for the update. In my program, I am only using toggle records, so I have only checked using toggle records, but I have confirmed that it works in Ver.1.3.

After my last post, I checked how OBS would respond to a toggle record request. The results are shown below, and in conclusion, I confirmed that bool outputActive was returned.

We found two cases where the OBS-WebSocket protocol sheet differed from the actual data sent from OBS. I understand that your code complies with the OBS protocol sheet. On the other hand, if OBS sends data that differs from the protocol, your code will appear to stop working from then on. This is caused by a lie in the protocol sheet or an error in the OBS send data, and is not a bug in your code. I have confirmed that this issue has been resolved. On the other hand, if the protocol sheet and the actual data sent by OBS are different, OBS Client will receive the next data, analyze it, and send it to my program instead of stopping the function as it currently does. I want you to. I would like the above to be a PullRequest.

04:21:22.429: [obs-websocket] [debug] [WebSocketServer::onMessage] Incoming message (decoded): 04:21:22.429: { 04:21:22.429: "d": { 04:21:22.429: "requestData": null, 04:21:22.429: "requestId": "0a6c01c9-a79e-423b-ab89-1075e4be5cf1", 04:21:22.429: "requestType": "ToggleRecord" 04:21:22.429: }, 04:21:22.429: "op": 6 04:21:22.429: } 04:21:22.429: [obs-websocket] [debug] [WebSocketServer::onMessage] Outgoing message: 04:21:22.429: { 04:21:22.429: "d": { 04:21:22.429: "requestId": "0a6c01c9-a79e-423b-ab89-1075e4be5cf1", 04:21:22.429: "requestStatus": { 04:21:22.429: "code": 100, 04:21:22.429: "result": true 04:21:22.429: }, 04:21:22.429: "requestType": "ToggleRecord", 04:21:22.429: "responseData": { 04:21:22.429: "outputActive": false 04:21:22.429: } 04:21:22.429: }, 04:21:22.429: "op": 7 04:21:22.429: }

[Parfaitomcat]

@tinodo

I reported to the OBS Websocket community regarding #2 and #4 that the LOG and documentation are different. these are Managed as OBS-WebSocket #1176. I believe that if this report is approved, the document will be revised.