Symptom
OpsDec stopped showing streams from Plex and Emby for an extended period even though both servers were reachable and other clients could connect. Sappho streams still worked because its WebSocket happened to stay alive.
Root cause
The WebSocket reconnect logic in each service (plex.js, emby.js, jellyfin.js) caps reconnection attempts at 10, then logs:
```
⚠️ Max Plex WebSocket reconnection attempts (10) reached. Giving up.
```
…and never attempts again. Once it gives up, the only way to recover is to restart the container. In the real world, upstream media servers restart for updates or network blips all the time, and 10 × 64s ≈ 10 minutes is easily exceeded.
Log evidence (from prod)
```
⚠️ Max Jellyfin WebSocket reconnection attempts (10) reached. Giving up.
✅ Plex WebSocket connected ← brief recovery
✅ Emby WebSocket connected
✅ Jellyfin WebSocket connected
✅ Sappho WebSocket connected
⚠️ Max Plex WebSocket reconnection attempts (10) reached. Giving up.
⚠️ Max Emby WebSocket reconnection attempts (10) reached. Giving up.
(Sappho keeps reconnecting forever — that path works)
```
Only Sappho kept the dashboard updated; Plex/Emby sessions never showed until the container was restarted manually.
Proposed fix
Remove the hard cap entirely and keep reconnecting indefinitely with exponential backoff, capped at a reasonable ceiling (e.g. 5 minutes). Matches what the Sappho service appears to already do. Optionally:
- Surface a "degraded" banner in the UI when a service's WebSocket has been disconnected for >N minutes so the operator can notice sooner
- Expose a "reconnect now" admin action as an escape hatch
Where to look
- `backend/src/services/plex.js` — `reconnectAttempts` / `MAX_RECONNECT_ATTEMPTS`
- `backend/src/services/emby.js` — same pattern
- `backend/src/services/jellyfin.js` — same pattern
- `backend/src/services/sappho.js` — reference for the "keep trying" pattern
Workaround
Restart the OpsDec container when streams from Plex/Emby stop appearing on the dashboard.
Symptom
OpsDec stopped showing streams from Plex and Emby for an extended period even though both servers were reachable and other clients could connect. Sappho streams still worked because its WebSocket happened to stay alive.
Root cause
The WebSocket reconnect logic in each service (plex.js, emby.js, jellyfin.js) caps reconnection attempts at 10, then logs:
```
⚠️ Max Plex WebSocket reconnection attempts (10) reached. Giving up.
```
…and never attempts again. Once it gives up, the only way to recover is to restart the container. In the real world, upstream media servers restart for updates or network blips all the time, and 10 × 64s ≈ 10 minutes is easily exceeded.
Log evidence (from prod)
```
⚠️ Max Jellyfin WebSocket reconnection attempts (10) reached. Giving up.
⚠️ Max Plex WebSocket reconnection attempts (10) reached. Giving up.
⚠️ Max Emby WebSocket reconnection attempts (10) reached. Giving up.
✅ Plex WebSocket connected ← brief recovery
✅ Emby WebSocket connected
✅ Jellyfin WebSocket connected
✅ Sappho WebSocket connected
(Sappho keeps reconnecting forever — that path works)
```
Only Sappho kept the dashboard updated; Plex/Emby sessions never showed until the container was restarted manually.
Proposed fix
Remove the hard cap entirely and keep reconnecting indefinitely with exponential backoff, capped at a reasonable ceiling (e.g. 5 minutes). Matches what the Sappho service appears to already do. Optionally:
Where to look
Workaround
Restart the OpsDec container when streams from Plex/Emby stop appearing on the dashboard.