GStreamer pipeline fails to re-patch audio output after long pause (~8 min), causing silent output #151
Description
Bug: GStreamer pipeline fails to re-patch audio output after long pause (>~8 min), causing silent output
Repository: openbroadcaster/obplayer
Description
When the player is paused via the web UI for approximately 8–10 minutes or longer, resuming playback causes the GStreamer audio pipeline to fail to reconnect its output. The player logs show it briefly patching and starting a track, then unpatching again 2–4 seconds later, falling into a rapid show paused break spin-loop. Audio output to the broadcast chain is silenced until the issue self-resolves (which can take 15–35 minutes of looping) or the player is manually restarted.
Short pauses (under ~1 minute) resume correctly with no issue.
Steps to Reproduce
- Have a show scheduled and playing normally via the scheduler.
- Pause playback using the web UI pause button.
- Leave the player paused for approximately 8–10 minutes or more.
- Resume playback via the web UI.
Expected: Playback resumes normally and audio output is restored to the output pipeline.
Actual: The player enters a tight spin-loop of show paused break entries. Occasionally it briefly patches and starts a real track, but the pipeline unpatches again within 2–4 seconds. No audio is output. The loop may self-resolve after many minutes, or may require a manual restart.
Evidence from Logs
The following sequence repeats thousands of times per minute during the failure state:
[Feb 27 2026 19:38:33 UTC] [debug] audio-break: stopped by stop request
[Feb 27 2026 19:38:33 UTC] [player] now playing track ?: unknown - show paused break (id: 0 file: duration: 4886.180057764053s type: 'break' source: scheduler)
[Feb 27 2026 19:38:33 UTC] [debug] audio-break: stopped by execute request
[Feb 27 2026 19:38:33 UTC] [debug] audio-break: stopped by stop request
[Feb 27 2026 19:38:33 UTC] [error] gstreamer failed waiting for state change to <enum GST_STATE_VOID_PENDING of type Gst.State>
When a real track briefly resumes, it patches then immediately unpatches:
[Feb 27 2026 19:57:24 UTC] [player] now playing track 14: Diamond Dino - Killdozer (...)
[Feb 27 2026 19:57:24 UTC] [debug] audio-playbin: patching audio/visual
[Feb 27 2026 19:57:24 UTC] [debug] audio-playbin: stopped by execute request
[Feb 27 2026 19:57:28 UTC] [debug] audio-playbin: stopped by stop request
[Feb 27 2026 19:57:28 UTC] [player] now playing track ?: unknown - show paused break (...)
[Feb 27 2026 19:57:28 UTC] [debug] audio-playbin: stopped by repatch outputs
[Feb 27 2026 19:57:28 UTC] [debug] audio-playbin: unpatching audio/visual
The GStreamer GST_STATE_VOID_PENDING error appears to be a state machine race condition triggered during pipeline teardown after a long idle period.
There was also a post-resume GStreamer warning (observed after a manual restart following this issue) suggesting a possible related pipeline configuration problem:
[warning] gstreamer warning: gst-core-error-quark: Pipeline construction is invalid, please add queues. (13)
[warning] gstreamer warning: gst-stream-error-quark: not negotiated (11), .../GstAudioResample:audio-out-pre-resample
Observed Silence Periods (from one incident log)
| Pause started (UTC) | Audio recovered (UTC) | Silence duration |
|---|---|---|
| 19:13:45 | 19:14:41 | ~1 min — recovered normally |
| 19:20:24 | 19:21:19 | ~1 min — recovered normally |
| 19:29:59 | ~19:57 | ~27 min |
| (continuing loop) | 20:13:33 | +16 min |
| 20:18:28 | ~20:38–20:54 | ~20–35 min |
Environment
- OBPlayer version: 5.3.0-20251204 (server: 5.3.6-20251222)
- OS: Ubuntu 24
- Audio output: GStreamer interpipe → Axia QOR 16 (via RTP/line input)
- Player mode: Scheduler with web UI pause/resume
Suspected Cause
The GStreamer pipeline appears to enter an unrecoverable or inconsistent state when left idle (paused) for an extended period. On resume, the state machine attempts a transition to GST_STATE_VOID_PENDING and fails, leaving the pipeline unable to re-establish its output patch. The scheduler detects end-of-content immediately (since there is no active stream), which re-triggers the break, creating the spin-loop.
A possible fix may involve explicitly tearing down and reinitializing the GStreamer pipeline on resume if it has been paused beyond a certain threshold, rather than attempting to resume from the existing (potentially stale) pipeline state.
Workaround
Manually restarting the player via the web UI (Admin > Delete DB and restart) restores normal playback, though there is a brief moment of fallback audio while show data re-syncs from the server.