starred/jellyfin

Fork 0

mirror of https://github.com/jellyfin/jellyfin.git synced 2026-01-23 23:20:51 +01:00

[Group] Jellyfin 10.11.0 bugs & issues #7451

New issue

Open

opened 2025-12-22 05:46:48 +01:00 by backuprepo · 3 comments

backuprepo commented

2025-12-22 05:46:48 +01:00

Owner

Originally created by @theguymadmax on GitHub (Oct 20, 2025).

This issue tracks general bugs related to 10.11.0

Performance issues tracked here: #15685
Migration and database issues tracked: #15686

Originally created by @theguymadmax on GitHub (Oct 20, 2025). This issue tracks general bugs related to [10.11.0](https://jellyfin.org/posts/jellyfin-release-10.11.0) Performance issues tracked here: #15685 Migration and database issues tracked: #15686

backuprepo added the

roadmap

label 2025-12-22 05:46:48 +01:00

backuprepo commented

2025-12-22 05:46:50 +01:00

Author

Owner

@necrosmash commented on GitHub (Oct 24, 2025):

This one only affected me when I upgraded to 10.11.0:
https://github.com/jellyfin/jellyfin/issues/15074

@necrosmash commented on GitHub (Oct 24, 2025): This one only affected me when I upgraded to 10.11.0: https://github.com/jellyfin/jellyfin/issues/15074

backuprepo commented

2025-12-22 05:46:52 +01:00

Author

Owner

@y0grt commented on GitHub (Nov 4, 2025):

thanks for creating a check to prevent launch when migrating from any other version than 10.10.7 👍

@y0grt commented on GitHub (Nov 4, 2025): thanks for creating a check to prevent launch when migrating from any other version than 10.10.7 👍

backuprepo commented

2025-12-22 05:46:55 +01:00

Author

Owner

@GrantM28 commented on GitHub (Dec 4, 2025):

Jellyfin 10.11.4 Crashes When WebSocket Client Disconnects Abruptly (Unhandled ObjectDisposedException

Jellyfin crashes entirely when a connected WebSocket client (Chrome browser) disconnects abruptly during shutdown or sleep. Instead of gracefully closing the session, Jellyfin throws an unhandled ObjectDisposedException originating from ManagedWebSocket, which bubbles up to Main and terminates the whole server process.

This occurs consistently when a client with the Dashboard open is shut down without completing a proper WebSocket close handshake.

This appears to be an unhandled WebSocket disconnect path that should be caught and ignored. A client dropping connection should never crash the server.

⸻

Environment
• Jellyfin Version: 10.11.4
• Platform: Unraid (Docker)
• Reverse Proxy: Nginx Proxy Manager (WebSocket headers enabled)
• Client Causing Crash: Google Chrome on Windows (192.168.1.6)
• Reproducibility: 100%

⸻

Steps to Reproduce
1. Open the Jellyfin Dashboard in Chrome on a Windows PC.
2. Shut down the PC or disconnect it from the network abruptly (e.g., Wi-Fi drop, sleep, NIC power-off).
3. Within seconds, Jellyfin logs show a WebSocket close error followed by an unhandled exception.
4. The Jellyfin server process crashes and restarts.

⸻

Expected Behavior
• Jellyfin should gracefully handle unexpected WebSocket disconnects.
• Client session should close cleanly.
• Server should continue running without interruption.

⸻

Actual Behavior

An abrupt client disconnect triggers a fatal, unhandled exception:

WS 192.168.1.6 error receiving data: The remote party closed the WebSocket connection without completing the close handshake
Unhandled exception: System.ObjectDisposedException: Cannot access a disposed object.
...
System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(...)
...
OperationCanceledException: The operation was canceled.

Jellyfin then terminates completely.

⸻

Relevant Logs

[WRN] Emby.Server.Implementations.HttpServer.WebSocketConnection:
WS 192.168.1.6 error receiving data: The remote party closed the WebSocket connection without completing the close handshake

[ERR] Microsoft.AspNetCore.Server.Kestrel: Unexpected exception in TimingPipeFlusher.FlushAsync

System.ObjectDisposedException: Cannot access a disposed object.
at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(...)
at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(...)

[FATAL] Main: Unhandled Exception
OperationCanceledException: The operation was canceled.

⸻

Additional Notes
• This only occurs when the Dashboard is open, which maintains an active WebSocket session.
• Normal playback sessions do not appear to trigger this issue.
• Disabling WebSocket keepalive pings reduces how often it happens but does not eliminate the root bug.
• A misbehaving or abruptly closing client should not crash the entire server.

⸻

Request

Please implement proper exception handling around WebSocket disconnect paths (especially in ManagedWebSocket.SendFrameFallbackAsync and session keepalive) so that unexpected client closures do not crash Jellyfin.

@GrantM28 commented on GitHub (Dec 4, 2025): Jellyfin 10.11.4 Crashes When WebSocket Client Disconnects Abruptly (Unhandled ObjectDisposedException Jellyfin crashes entirely when a connected WebSocket client (Chrome browser) disconnects abruptly during shutdown or sleep. Instead of gracefully closing the session, Jellyfin throws an unhandled ObjectDisposedException originating from ManagedWebSocket, which bubbles up to Main and terminates the whole server process. This occurs consistently when a client with the Dashboard open is shut down without completing a proper WebSocket close handshake. This appears to be an unhandled WebSocket disconnect path that should be caught and ignored. A client dropping connection should never crash the server. ⸻ Environment • Jellyfin Version: 10.11.4 • Platform: Unraid (Docker) • Reverse Proxy: Nginx Proxy Manager (WebSocket headers enabled) • Client Causing Crash: Google Chrome on Windows (192.168.1.6) • Reproducibility: 100% ⸻ Steps to Reproduce 1. Open the Jellyfin Dashboard in Chrome on a Windows PC. 2. Shut down the PC or disconnect it from the network abruptly (e.g., Wi-Fi drop, sleep, NIC power-off). 3. Within seconds, Jellyfin logs show a WebSocket close error followed by an unhandled exception. 4. The Jellyfin server process crashes and restarts. ⸻ Expected Behavior • Jellyfin should gracefully handle unexpected WebSocket disconnects. • Client session should close cleanly. • Server should continue running without interruption. ⸻ Actual Behavior An abrupt client disconnect triggers a fatal, unhandled exception: WS 192.168.1.6 error receiving data: The remote party closed the WebSocket connection without completing the close handshake Unhandled exception: System.ObjectDisposedException: Cannot access a disposed object. ... System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(...) ... OperationCanceledException: The operation was canceled. Jellyfin then terminates completely. ⸻ Relevant Logs [WRN] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS 192.168.1.6 error receiving data: The remote party closed the WebSocket connection without completing the close handshake [ERR] Microsoft.AspNetCore.Server.Kestrel: Unexpected exception in TimingPipeFlusher.FlushAsync System.ObjectDisposedException: Cannot access a disposed object. at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(...) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(...) [FATAL] Main: Unhandled Exception OperationCanceledException: The operation was canceled. ⸻ Additional Notes • This only occurs when the Dashboard is open, which maintains an active WebSocket session. • Normal playback sessions do not appear to trigger this issue. • Disabling WebSocket keepalive pings reduces how often it happens but does not eliminate the root bug. • A misbehaving or abruptly closing client should not crash the entire server. ⸻ Request Please implement proper exception handling around WebSocket disconnect paths (especially in ManagedWebSocket.SendFrameFallbackAsync and session keepalive) so that unexpected client closures do not crash Jellyfin.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#7451

No description provided.

Rows
Columns