Hello everyone, I've had an issue since the get-go with my IRL streaming that's been driving me crazy, and I've steadily narrowed it down to OBS itself. On the occasions when I lose signal during a livestream, Moblin (my streaming app) is unable to reestablish a connection to OBS - the only way an SRT feed can be revived is to remote in to OBS via TeamViewer to stop the outgoing Twitch stream and begin a new session. Below is the full write-up I posted to Github. For full transparency, I've been working with Claude to diagnose this and we've been experimenting with all other avenues for several days, and looking at the log files (attached) the diagnosis seemed to hold water:
### Description
A Media Source configured to receive SRT in listener mode (`srt://0.0.0.0:PORT?mode=listener`) cannot recreate its socket on reconnect while OBS has any active output (recording, streaming, or both).
When the upstream SRT caller disconnects, the source correctly logs `[Media Source]: Disconnected. Reconnecting...` and begins reconnection attempts. While an output is active, every reconnect attempt fails with `error: Connection setup failure: unable to create/configure SRT socket`, repeating once per second indefinitely. The source recovers within ~5 seconds of all outputs being stopped.
When OBS is idle (no active outputs), the same source disconnects and reconnects cleanly with no errors.
This appears to be a socket lifecycle bug where the SRT listener socket isn't released for re-binding while a downstream consumer (the active output's encoder pipeline) holds a reference to the source.
### Steps to Reproduce
1. Add a Media Source with input URL `srt://0.0.0.0:9999?mode=listener&latency=2000`
2. Stream SRT into port 9999 from any caller-mode source (in my case, an iPhone running Moblin)
3. Confirm the source is active and rendering
4. Start Recording (or Streaming) in OBS
5. Cause the upstream SRT input to disconnect (e.g., put the streaming device into airplane mode)
6. Wait briefly for OBS to register `[Media Source]: Disconnected. Reconnecting...`
7. Restore the upstream SRT input. **Observe:** the source does not reconnect; OBS logs `Connection setup failure: unable to create/configure SRT socket` every ~1 second indefinitely.
8. Stop Recording (and/or Streaming). **Observe:** within ~5 seconds, the source reconnects normally.
### Expected Behavior
The SRT Media Source should be able to recreate its listener socket on reconnect regardless of OBS output state, matching its behaviour when OBS is idle.
### Actual Behavior
SRT socket recreation fails with `Connection setup failure: unable to create/configure SRT socket` for every reconnect attempt while any output is active. Source only recovers after all outputs are stopped.
### Log Evidence
Single-session timeline (log file `2026-05-30 12-41-18.txt`):
```
12:41:44.219: ==== Recording Start ===============================================
12:42:15.960: [Media Source 'Moblin SRT']: Disconnected. Reconnecting...
12:42:16.961: error: Connection setup failure: unable to create/configure SRT socket
[... 83 identical errors at ~1s intervals ...]
12:43:40.413: ==== Recording Stop ================================================
12:43:45.151: [Media Source 'Moblin SRT']: Reconnected.
```
Same source had several subsequent disconnect/reconnect cycles between 12:43 and 15:54 **with no output active** — every one reconnected cleanly with zero `Connection setup failure` errors.
Pattern is consistent across multiple sessions:
| Log file | `Connection setup failure` errors during recording |
|---|---|
| 2026-05-26 17-31-01.txt | 248 |
| 2026-05-26 18-25-09.txt | 178 |
| 2026-05-27 08-38-54.txt | 117 |
| 2026-05-30 08-43-56.txt | 90 |
| 2026-05-30 09-00-21.txt | 617 |
| 2026-05-30 12-41-18.txt | 83 |
### Variables Ruled Out During Diagnosis
To save triage time, the following were eliminated as causes:
- **obs-websocket plugin (5.7.3):** Independently verified that new WebSocket client connections succeed during recording (tested with the Simple WebSocket Client Chrome extension connecting to `ws://localhost:4455` directly).
- **External network layer (Cloudflare Tunnel):** Bug reproduces with all external network paths bypassed.
- **Encoder load:** CPU usage was ~3-4% on NVIDIA NVENC during reproduction. Bug also reproduces with x264 software encoder.
- **WebSocket clients:** No third-party WS clients (e.g. IRLLink, control apps) need to be connected for the bug to reproduce.
- **Plugin interference:** Bug reproduces with default plugin set.
### Workaround
Stop all active outputs to allow the SRT source to reconnect, then restart outputs.
### Environment
- **OBS Studio version:** 32.1.2 (64-bit, Windows)
- **Operating system:** Windows 11 24H2 (Build 26200)
- **CPU:** Intel Core i9-9900K
- **GPU:** NVIDIA GeForce RTX 4070 SUPER, driver 32.0.16.1047
- **Memory:** 32 GB
- **Encoder used during repro:** NVIDIA NVENC (HEVC); also reproduces with x264
- **obs-websocket plugin:** 5.7.3 (irrelevant to bug, listed for completeness)
- **OBS launched with admin privileges:** No
- **Crash on this issue:** No
### Description
A Media Source configured to receive SRT in listener mode (`srt://0.0.0.0:PORT?mode=listener`) cannot recreate its socket on reconnect while OBS has any active output (recording, streaming, or both).
When the upstream SRT caller disconnects, the source correctly logs `[Media Source]: Disconnected. Reconnecting...` and begins reconnection attempts. While an output is active, every reconnect attempt fails with `error: Connection setup failure: unable to create/configure SRT socket`, repeating once per second indefinitely. The source recovers within ~5 seconds of all outputs being stopped.
When OBS is idle (no active outputs), the same source disconnects and reconnects cleanly with no errors.
This appears to be a socket lifecycle bug where the SRT listener socket isn't released for re-binding while a downstream consumer (the active output's encoder pipeline) holds a reference to the source.
### Steps to Reproduce
1. Add a Media Source with input URL `srt://0.0.0.0:9999?mode=listener&latency=2000`
2. Stream SRT into port 9999 from any caller-mode source (in my case, an iPhone running Moblin)
3. Confirm the source is active and rendering
4. Start Recording (or Streaming) in OBS
5. Cause the upstream SRT input to disconnect (e.g., put the streaming device into airplane mode)
6. Wait briefly for OBS to register `[Media Source]: Disconnected. Reconnecting...`
7. Restore the upstream SRT input. **Observe:** the source does not reconnect; OBS logs `Connection setup failure: unable to create/configure SRT socket` every ~1 second indefinitely.
8. Stop Recording (and/or Streaming). **Observe:** within ~5 seconds, the source reconnects normally.
### Expected Behavior
The SRT Media Source should be able to recreate its listener socket on reconnect regardless of OBS output state, matching its behaviour when OBS is idle.
### Actual Behavior
SRT socket recreation fails with `Connection setup failure: unable to create/configure SRT socket` for every reconnect attempt while any output is active. Source only recovers after all outputs are stopped.
### Log Evidence
Single-session timeline (log file `2026-05-30 12-41-18.txt`):
```
12:41:44.219: ==== Recording Start ===============================================
12:42:15.960: [Media Source 'Moblin SRT']: Disconnected. Reconnecting...
12:42:16.961: error: Connection setup failure: unable to create/configure SRT socket
[... 83 identical errors at ~1s intervals ...]
12:43:40.413: ==== Recording Stop ================================================
12:43:45.151: [Media Source 'Moblin SRT']: Reconnected.
```
Same source had several subsequent disconnect/reconnect cycles between 12:43 and 15:54 **with no output active** — every one reconnected cleanly with zero `Connection setup failure` errors.
Pattern is consistent across multiple sessions:
| Log file | `Connection setup failure` errors during recording |
|---|---|
| 2026-05-26 17-31-01.txt | 248 |
| 2026-05-26 18-25-09.txt | 178 |
| 2026-05-27 08-38-54.txt | 117 |
| 2026-05-30 08-43-56.txt | 90 |
| 2026-05-30 09-00-21.txt | 617 |
| 2026-05-30 12-41-18.txt | 83 |
### Variables Ruled Out During Diagnosis
To save triage time, the following were eliminated as causes:
- **obs-websocket plugin (5.7.3):** Independently verified that new WebSocket client connections succeed during recording (tested with the Simple WebSocket Client Chrome extension connecting to `ws://localhost:4455` directly).
- **External network layer (Cloudflare Tunnel):** Bug reproduces with all external network paths bypassed.
- **Encoder load:** CPU usage was ~3-4% on NVIDIA NVENC during reproduction. Bug also reproduces with x264 software encoder.
- **WebSocket clients:** No third-party WS clients (e.g. IRLLink, control apps) need to be connected for the bug to reproduce.
- **Plugin interference:** Bug reproduces with default plugin set.
### Workaround
Stop all active outputs to allow the SRT source to reconnect, then restart outputs.
### Environment
- **OBS Studio version:** 32.1.2 (64-bit, Windows)
- **Operating system:** Windows 11 24H2 (Build 26200)
- **CPU:** Intel Core i9-9900K
- **GPU:** NVIDIA GeForce RTX 4070 SUPER, driver 32.0.16.1047
- **Memory:** 32 GB
- **Encoder used during repro:** NVIDIA NVENC (HEVC); also reproduces with x264
- **obs-websocket plugin:** 5.7.3 (irrelevant to bug, listed for completeness)
- **OBS launched with admin privileges:** No
- **Crash on this issue:** No