Intermittent crashing when jellyfin tries to access a websocket that has been disposed #7340

Open
opened 2025-12-22 05:34:24 +01:00 by backuprepo · 8 comments
Owner

Originally created by @Sandermoen on GitHub (Sep 22, 2025).

Description of the bug

Keeping the server running normally in Unraid will make it crash after a random amount of days/hours, I am unsure if this bug is present in installs that are not within Docker and Unraid. I've had the Jellyfin instance running concurrently for a month before and then suddenly it crashes or it might crash within the hour, very random seeminlgy.
This issue has persisted through several Jellyfin versions and is still present now.

Reproduction steps

  1. Install Jellyfin through Unraid
  2. Keep it running for a few days/weeks
  3. Crashes with error Cannot access a disposed object.

What is the current bug behavior?

The server crashes after X amount of days with the error System.ObjectDisposedException: Cannot access a disposed object.
Seemingly trying to close a socket connection that doesn't exist anymore. Possibly a race condition?

What is the expected correct behavior?

The server shouldn't crash and should handle and check that a socket is in an acceptable state/isn't already closed when attempting to close the connection.

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

No response

Specify the build version

10.10.7

Environment

- OS: Unraid
- Linux Kernel: 6.1.106-Unraid
- Virtualization: Docker
- Clients: IOS, Android, Browser, Chromecast
- Browser: Chrome 140.0.7339.185
- FFmpeg Version: 7.0.2-Jellyfin
- Playback Method: Direct Play, Remux, Direct Stream, Transcode
- Hardware Acceleration: NVENC
- GPU Model: 1650 Super
- Plugins: None
- Reverse Proxy: None
- Base URL: none
- Networking: Host
- Jellyfin Data Storage: Local Sata SSD
- Media Storage: Local Sata HDD Array
- External Integrations: Jellyseerr, Radarr, Sonarr, Bazarr, Sabnzbd

Jellyfin logs

System.ArgumentException: Can't create trickplay from 0 images.
   at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.CreateTiles(IReadOnlyList`1 images, Int32 width, TrickplayOptions options, String outputDir)
   at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.RefreshTrickplayDataInternal(Video video, Boolean replace, Int32 width, TrickplayOptions options, LibraryOptions libraryOptions, CancellationToken cancellationToken)
[2025-09-20 03:00:08.256 -07:00] [INF] [138] Emby.Server.Implementations.ScheduledTasks.TaskManager: "Generate Trickplay Images" Completed after 0 minute(s) and 8 seconds
[2025-09-20 03:01:56.572 -07:00] [WRN] [104] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "xxx.xx.xxx.xxx" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake."
[2025-09-20 03:01:56.579 -07:00] [INF] [104] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "xxx.xx.xxx.xxx" closed
[2025-09-20 03:01:56.604 -07:00] [FTL] [104] Main: Unhandled Exception
System.OperationCanceledException: The operation was canceled.
 ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.WebSockets.WebSocket'.
   at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan`1 payloadBuffer)
   at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken)
   at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e)
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
   at System.Threading.QueueUserWorkItemCallback.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
[2025-09-20 03:02:03.010 -07:00] [INF] [1] Main: Jellyfin version: "10.10.7"
[2025-09-20 03:02:03.031 -07:00] [INF] [1] Main: Environment Variables: ["[JELLYFIN_PublishedServerUrl, 192.168.0.5]", "[JELLYFIN_LOG_DIR, /config/log]", "[JELLYFIN_CACHE_DIR, /cache]", "[JELLYFIN_WEB_DIR, /jellyfin/jellyfin-web]", "[JELLYFIN_CONFIG_DIR, /config/config]", "[JELLYFIN_DATA_DIR, /config]", "[JELLYFIN_FFMPEG, /usr/lib/jellyfin-ffmpeg/ffmpeg]"]
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Arguments: ["/jellyfin/jellyfin.dll"]
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Operating system: "Debian GNU/Linux 12 (bookworm)"
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Architecture: X64
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: 64-Bit Process: True
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: User Interactive: True
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Processor count: 12
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Program data path: "/config"
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Log directory path: "/config/log"
[2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Config directory path: "/config/config"
[2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Cache path: "/cache"
[2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Temp directory path: "/tmp/jellyfin"
[2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Web resources path: "/jellyfin/jellyfin-web"
[2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Application directory: "/jellyfin/"
[2025-09-20 03:02:03.148 -07:00] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: "/cache"

FFmpeg logs


Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

Is it not possible to handle this error gracefully so the server at least doesn't suffer an unhandled exception and can keep on chugging?

Originally created by @Sandermoen on GitHub (Sep 22, 2025). ### Description of the bug Keeping the server running normally in Unraid will make it crash after a random amount of days/hours, I am unsure if this bug is present in installs that are not within Docker and Unraid. I've had the Jellyfin instance running concurrently for a month before and then suddenly it crashes or it might crash within the hour, very random seeminlgy. This issue has persisted through several Jellyfin versions and is still present now. ### Reproduction steps 1. Install Jellyfin through Unraid 2. Keep it running for a few days/weeks 3. Crashes with error Cannot access a disposed object. ### What is the current _bug_ behavior? The server crashes after X amount of days with the error System.ObjectDisposedException: Cannot access a disposed object. Seemingly trying to close a socket connection that doesn't exist anymore. Possibly a race condition? ### What is the expected _correct_ behavior? The server shouldn't crash and should handle and check that a socket is in an acceptable state/isn't already closed when attempting to close the connection. ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number _No response_ ### Specify the build version 10.10.7 ### Environment ```markdown - OS: Unraid - Linux Kernel: 6.1.106-Unraid - Virtualization: Docker - Clients: IOS, Android, Browser, Chromecast - Browser: Chrome 140.0.7339.185 - FFmpeg Version: 7.0.2-Jellyfin - Playback Method: Direct Play, Remux, Direct Stream, Transcode - Hardware Acceleration: NVENC - GPU Model: 1650 Super - Plugins: None - Reverse Proxy: None - Base URL: none - Networking: Host - Jellyfin Data Storage: Local Sata SSD - Media Storage: Local Sata HDD Array - External Integrations: Jellyseerr, Radarr, Sonarr, Bazarr, Sabnzbd ``` ### Jellyfin logs ```shell System.ArgumentException: Can't create trickplay from 0 images. at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.CreateTiles(IReadOnlyList`1 images, Int32 width, TrickplayOptions options, String outputDir) at Jellyfin.Server.Implementations.Trickplay.TrickplayManager.RefreshTrickplayDataInternal(Video video, Boolean replace, Int32 width, TrickplayOptions options, LibraryOptions libraryOptions, CancellationToken cancellationToken) [2025-09-20 03:00:08.256 -07:00] [INF] [138] Emby.Server.Implementations.ScheduledTasks.TaskManager: "Generate Trickplay Images" Completed after 0 minute(s) and 8 seconds [2025-09-20 03:01:56.572 -07:00] [WRN] [104] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "xxx.xx.xxx.xxx" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake." [2025-09-20 03:01:56.579 -07:00] [INF] [104] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "xxx.xx.xxx.xxx" closed [2025-09-20 03:01:56.604 -07:00] [FTL] [104] Main: Unhandled Exception System.OperationCanceledException: The operation was canceled. ---> System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.WebSockets.WebSocket'. at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan`1 payloadBuffer) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e) at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state) at System.Threading.QueueUserWorkItemCallback.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() [2025-09-20 03:02:03.010 -07:00] [INF] [1] Main: Jellyfin version: "10.10.7" [2025-09-20 03:02:03.031 -07:00] [INF] [1] Main: Environment Variables: ["[JELLYFIN_PublishedServerUrl, 192.168.0.5]", "[JELLYFIN_LOG_DIR, /config/log]", "[JELLYFIN_CACHE_DIR, /cache]", "[JELLYFIN_WEB_DIR, /jellyfin/jellyfin-web]", "[JELLYFIN_CONFIG_DIR, /config/config]", "[JELLYFIN_DATA_DIR, /config]", "[JELLYFIN_FFMPEG, /usr/lib/jellyfin-ffmpeg/ffmpeg]"] [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Arguments: ["/jellyfin/jellyfin.dll"] [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Operating system: "Debian GNU/Linux 12 (bookworm)" [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Architecture: X64 [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: 64-Bit Process: True [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: User Interactive: True [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Processor count: 12 [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Program data path: "/config" [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Log directory path: "/config/log" [2025-09-20 03:02:03.033 -07:00] [INF] [1] Main: Config directory path: "/config/config" [2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Cache path: "/cache" [2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Temp directory path: "/tmp/jellyfin" [2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Web resources path: "/jellyfin/jellyfin-web" [2025-09-20 03:02:03.034 -07:00] [INF] [1] Main: Application directory: "/jellyfin/" [2025-09-20 03:02:03.148 -07:00] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: "/cache" ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information Is it not possible to handle this error gracefully so the server at least doesn't suffer an unhandled exception and can keep on chugging?
backuprepo added the
bug
label 2025-12-22 05:34:24 +01:00
Author
Owner

@felix920506 commented on GitHub (Sep 23, 2025):

Can you enable debug logging?

@felix920506 commented on GitHub (Sep 23, 2025): Can you enable debug logging?
Author
Owner

@Sandermoen commented on GitHub (Sep 27, 2025):

Can you enable debug logging?

Enabled now, just waiting for it to crash again to collect more data :)

@Sandermoen commented on GitHub (Sep 27, 2025): > Can you enable debug logging? Enabled now, just waiting for it to crash again to collect more data :)
Author
Owner

@bakaxazian commented on GitHub (Oct 10, 2025):

Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post..
Please see:
https://github.com/jellyfin/jellyfin/issues/14974 for more info!

@bakaxazian commented on GitHub (Oct 10, 2025): Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post.. Please see: https://github.com/jellyfin/jellyfin/issues/14974 for more info!
Author
Owner

@gnattu commented on GitHub (Oct 10, 2025):

Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post.. Please see: #14974 for more info!

We would need debug logging for more detail as this is too hard to reproduce on our side

@gnattu commented on GitHub (Oct 10, 2025): > Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post.. Please see: [#14974](https://github.com/jellyfin/jellyfin/issues/14974) for more info! We would need debug logging for more detail as this is too hard to reproduce on our side
Author
Owner

@bakaxazian commented on GitHub (Oct 11, 2025):

Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post.. Please see: #14974 for more info!

We would need debug logging for more detail as this is too hard to reproduce on our side

Sounds good, turned on debugging like Sandermoen and will wait for another crash.

@bakaxazian commented on GitHub (Oct 11, 2025): > > Hello, i am having the exact same issue. I just closed the bug report i just created before i saw this post.. Please see: [#14974](https://github.com/jellyfin/jellyfin/issues/14974) for more info! > > We would need debug logging for more detail as this is too hard to reproduce on our side Sounds good, turned on debugging like Sandermoen and will wait for another crash.
Author
Owner

@bakaxazian commented on GitHub (Oct 12, 2025):

Hello all,

My server has crashed again due to what looks like the same issue:
Please see the debug log of when the crash happened.
Let me know if the full log is required,

Thanks!

[2025-10-12 130218.585 -0700] [INF].txt

@bakaxazian commented on GitHub (Oct 12, 2025): Hello all, My server has crashed again due to what looks like the same issue: Please see the debug log of when the crash happened. Let me know if the full log is required, Thanks! [\[2025-10-12 130218.585 -0700\] \[INF\].txt](https://github.com/user-attachments/files/22873735/2025-10-12.130218.585.-0700.INF.txt)
Author
Owner

@Lax4ever commented on GitHub (Dec 6, 2025):

Hello!

I can also confirm this issue exists on 10.11.4

Jellyfin Version 10.11.4 (non-portable)
Running on Windows 10

[2025-12-05 19:25:28.744 -06:00] [FTL] [50] Main: Unhandled Exception
System.OperationCanceledException: The operation was canceled.
---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.WebSockets.WebSocket'.
at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates)
at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan1 payloadBuffer) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory1 payloadBuffer, Task lockTask, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.WebSocketConnection.SendAsync[T](OutboundWebSocketMessage1 message, CancellationToken cancellationToken)
at Emby.Server.Implementations.Session.SessionWebSocketListener.SendForceKeepAlive(IWebSocketConnection webSocket)
at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e)
at System.Threading.Tasks.Task.<>c.b__128_1(Object state)
at System.Threading.QueueUserWorkItemCallback.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
[2025-12-05 19:25:31.367 -06:00] [FTL] [17] Main: Unhandled Exception
System.OperationCanceledException: The operation was canceled.
---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.WebSockets.WebSocket'.
at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates)
at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan1 payloadBuffer) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory1 payloadBuffer, Task lockTask, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.WebSocketConnection.SendAsync[T](OutboundWebSocketMessage1 message, CancellationToken cancellationToken)
at Emby.Server.Implementations.Session.SessionWebSocketListener.SendForceKeepAlive(IWebSocketConnection webSocket)
at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e)
at System.Threading.Tasks.Task.<>c.b__128_1(Object state)
at System.Threading.QueueUserWorkItemCallback.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

@Lax4ever commented on GitHub (Dec 6, 2025): Hello! I can also confirm this issue exists on 10.11.4 Jellyfin Version 10.11.4 (non-portable) Running on Windows 10 [2025-12-05 19:25:28.744 -06:00] [FTL] [50] Main: Unhandled Exception System.OperationCanceledException: The operation was canceled. ---> System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.WebSockets.WebSocket'. at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates) at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan`1 payloadBuffer) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.WebSocketConnection.SendAsync[T](OutboundWebSocketMessage`1 message, CancellationToken cancellationToken) at Emby.Server.Implementations.Session.SessionWebSocketListener.SendForceKeepAlive(IWebSocketConnection webSocket) at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e) at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state) at System.Threading.QueueUserWorkItemCallback.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart() [2025-12-05 19:25:31.367 -06:00] [FTL] [17] Main: Unhandled Exception System.OperationCanceledException: The operation was canceled. ---> System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.WebSockets.WebSocket'. at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates) at System.Net.WebSockets.ManagedWebSocket.WriteFrameToSendBuffer(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlySpan`1 payloadBuffer) at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.WebSockets.ManagedWebSocket.SendFrameFallbackAsync(MessageOpcode opcode, Boolean endOfMessage, Boolean disableCompression, ReadOnlyMemory`1 payloadBuffer, Task lockTask, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.WebSocketConnection.SendAsync[T](OutboundWebSocketMessage`1 message, CancellationToken cancellationToken) at Emby.Server.Implementations.Session.SessionWebSocketListener.SendForceKeepAlive(IWebSocketConnection webSocket) at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e) at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state) at System.Threading.QueueUserWorkItemCallback.Execute() at System.Threading.ThreadPoolWorkQueue.Dispatch() at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
Author
Owner

@JKamsker commented on GitHub (Dec 13, 2025):

I can confirm the same crash signature as this issue, but on macOS (not Docker/Unraid).

Environment

  • Jellyfin Server: 10.11.3 (macOS app at /Applications/Jellyfin.app)
  • OS: macOS 26.1 (Build 25B78), arm64
  • Hardware: Mac16,11 (12 CPU cores, 64 GB RAM)
  • Reverse proxy: none (direct LAN access)
  • Network: LAN clients on 10.0.0.0/24
  • Plugins (all from ~/Library/Application Support/jellyfin/plugins):
    • AniDB_11.0.0.0
    • AniSearch_6.0.0.0
    • TMDb Box Sets_12.0.0.0
    • TubeArchivistMetadata_1.4.4.0 (sync tasks disabled; they log “synchronization is currently disabled” and exit quickly)

What happened

On 2025-12-13 00:31:59 (+01:00) a LAN client (10.0.0.44) dropped a WebSocket without completing the close handshake.
Jellyfin then attempted a keep-alive / send on a socket that was already Aborted/disposed, and the server crashed with an unhandled exception.

Result / impact

  • Jellyfin process terminates and stops responding.
  • Requires manual restart of the macOS app to recover.

Logs (crash excerpt)

[2025-12-13 00:31:59.625 +01:00] [WRN] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "10.0.0.44" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake."
[2025-12-13 00:31:59.627 +01:00] [INF] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "10.0.0.44" closed
[2025-12-13 00:31:59.634 +01:00] [FTL] Main: Unhandled Exception
System.OperationCanceledException: The operation was canceled.
 ---> System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.WebSockets.WebSocket'.
   at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates)
   ...
   at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e)

Repro (best guess)

  1. Start Jellyfin
  2. Connect a client that uses WebSockets (web UI / TV app / mobile app)
  3. Force an unclean disconnect (force-quit client, sleep device, network drop)
  4. Wait for server WebSocket keep-alive
@JKamsker commented on GitHub (Dec 13, 2025): I can confirm the same crash signature as this issue, but on **macOS** (not Docker/Unraid). ### Environment - Jellyfin Server: **10.11.3** (macOS app at `/Applications/Jellyfin.app`) - OS: **macOS 26.1** (Build **25B78**), **arm64** - Hardware: **Mac16,11** (12 CPU cores, 64 GB RAM) - Reverse proxy: **none** (direct LAN access) - Network: LAN clients on `10.0.0.0/24` - Plugins (all from `~/Library/Application Support/jellyfin/plugins`): - AniDB_11.0.0.0 - AniSearch_6.0.0.0 - TMDb Box Sets_12.0.0.0 - TubeArchivistMetadata_1.4.4.0 (sync tasks disabled; they log “synchronization is currently disabled” and exit quickly) ### What happened On **2025-12-13 00:31:59 (+01:00)** a LAN client (`10.0.0.44`) dropped a WebSocket without completing the close handshake. Jellyfin then attempted a keep-alive / send on a socket that was already `Aborted`/disposed, and the server crashed with an **unhandled** exception. ### Result / impact - Jellyfin process terminates and stops responding. - Requires **manual restart** of the macOS app to recover. ### Logs (crash excerpt) ```text [2025-12-13 00:31:59.625 +01:00] [WRN] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "10.0.0.44" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake." [2025-12-13 00:31:59.627 +01:00] [INF] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "10.0.0.44" closed [2025-12-13 00:31:59.634 +01:00] [FTL] Main: Unhandled Exception System.OperationCanceledException: The operation was canceled. ---> System.ObjectDisposedException: Cannot access a disposed object. Object name: 'System.Net.WebSockets.WebSocket'. at System.Net.WebSockets.ManagedWebSocket.ThrowIfInvalidState(WebSocketState[] validStates) ... at Emby.Server.Implementations.Session.SessionWebSocketListener.KeepAliveSockets(Object o, EventArgs e) ``` ### Repro (best guess) 1. Start Jellyfin 2. Connect a client that uses WebSockets (web UI / TV app / mobile app) 3. Force an unclean disconnect (force-quit client, sleep device, network drop) 4. Wait for server WebSocket keep-alive
Sign in to join this conversation.
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#7340
No description provided.