Latest version of Emby - Random lockups - Connection Timeout to https://api4.thetvdb.com

[vaise 342]

This has happened twice in 2 days now - An Emby restart fixes it.  Unlike the first time, this time I was in a position to get some logs.

It seems this happens over and over - the below is repeated 25,000 lines in the logs, all in the same few seconds.  Emby is just a spinning disk when this happens.  I know you will be asking for the full log, so I will also upload that.  If there is a comms issue, or if there is an API issue, this should not stop Emby working should it ?

See the log of 25,000 lines all at 19:10.00 ish.

2026-09-15 19:10:00.479 Error TvShowsService-0HNOHVPFMI8ME:0000000D: Error getting episode listing
    *** Error Report ***
    Version: 4.10.0.40
    Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
    Operating system: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul  6 15:22:03 PDT 2026
    OS/Process: x64/x64
    Framework: .NET 8.0.28
    Runtime: system/System.Private.CoreLib.dll
    Processor count: 12
    Data path: /config
    Application path: /system
    MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: Connection to https://api4.thetvdb.com/v4/series/412427/episodes/official?page=0 timed out
     ---> System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 20 seconds elapsing.
     ---> System.TimeoutException: The operation was canceled.
     ---> System.Threading.Tasks.TaskCanceledException: The operation was canceled.
     ---> System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
     ---> System.Net.Sockets.SocketException (125): Operation canceled
       --- End of inner exception stack trace ---
       at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)
       at System.Net.Security.SslStream.EnsureFullTlsFrameAsync[TIOAdapter](CancellationToken cancellationToken, Int32 estimatedSize)
       at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
       at System.Net.Security.SslStream.ReadAsyncInternal[TIOAdapter](Memory`1 buffer, CancellationToken cancellationToken)
       at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
       at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       --- End of inner exception stack trace ---
       at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
       at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
       --- End of inner exception stack trace ---
       --- End of inner exception stack trace ---
       at System.Net.Http.HttpClient.HandleFailure(Exception e, Boolean telemetryStarted, HttpResponseMessage response, CancellationTokenSource cts, CancellationToken cancellationToken, CancellationTokenSource pendingRequestsCts)
       at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
       --- End of inner exception stack trace ---
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
       at Emby.Server.Implementations.HttpClientManager.BaseHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod)
       at Tvdb.EntryPoint.GetResponse(HttpRequestOptions request, String method)
       at Tvdb.TvdbEpisodeProvider.FetchEpisodes(String url, Int32 page, CancellationToken cancellationToken)
       at Tvdb.TvdbEpisodeProvider.FetchEpisodesWithAllPages(String url, CancellationToken cancellationToken)
       at Tvdb.TvdbEpisodeProvider.FetchMainResult(String seriesId, String seasonType, CancellationToken cancellationToken)
       at Tvdb.TvdbEpisodeProvider.EnsureEpisodesInfo(String id, String seasonType, TimeSpan cacheTime, IDirectoryService directoryService, CancellationToken cancellationToken)
       at Tvdb.TvdbSeriesProvider.GetAllEpisodes(SeriesInfo seriesInfo, CancellationToken cancellationToken)
       at Emby.Api.TvShowsService.GetAllEpisodes(Series series, Season season, LibraryOptions libraryOptions, Nullable`1 isUnaired, Nullable`1 isMissing, Nullable`1 isSpecial, CancellationToken cancellationToken)
       at Emby.Api.TvShowsService.GetAllEpisodes(User user, DtoOptions dtoOptions, String parentId, Nullable`1 isUnaired, Nullable`1 isMissing, Nullable`1 isSpecial, Boolean sortItems, Nullable`1 startIndex, Nullable`1 limit, CancellationToken cancellationToken)
    Source: Emby.Server.Implementations
    TargetSite: Void MoveNext()
    InnerException: System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 20 seconds elapsing.
    Source: System.Net.Http
    TargetSite: Void HandleFailure(System.Exception, Boolean, System.Net.Http.HttpResponseMessage, System.Threading.CancellationTokenSource, System.Threading.CancellationToken, System.Threading.CancellationTokenSource)
       at System.Net.Http.HttpClient.HandleFailure(Exception e, Boolean telemetryStarted, HttpResponseMessage response, CancellationTokenSource cts, CancellationToken cancellationToken, CancellationTokenSource pendingRequestsCts)
       at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
    InnerException: System.TimeoutException: The operation was canceled.
    Source: 
    TargetSite: 
    InnerException: System.Threading.Tasks.TaskCanceledException: The operation was canceled.
    Source: System.Net.Http
    TargetSite: Void MoveNext()
       at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
       at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
       at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
    InnerException: System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
    Source: System.Net.Sockets
    TargetSite: Int32 System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16)
       at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token)
       at System.Net.Security.SslStream.EnsureFullTlsFrameAsync[TIOAdapter](CancellationToken cancellationToken, Int32 estimatedSize)
       at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
       at System.Net.Security.SslStream.ReadAsyncInternal[TIOAdapter](Memory`1 buffer, CancellationToken cancellationToken)
       at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
       at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
    InnerException: System.Net.Sockets.SocketException: Operation canceled
    Source: 
    TargetSite: 
    
 

 

embyserver-63925096289.txt

[vaise 342]

Further info - This is running on a docker container on Unraid.

I have been stable for ages.  New version installed 3 days back.

[Luke 43161]

hi there, what makes you think Emby stops working?

[Luke 43161]

What I can see is that something external is hammering your server with requests for episode listings and this is causing huge numbers of requests to go out to tvdb.

[vaise 342]

I have not changed anything for a long while.  Except emby upgrade.  By all means I can shutdown jellyseer, which if the only external thing.  But it has its own request thing, it does not request emby do this.

[vaise 342]

The log I imagine shows my plugins.  Could it be conversant or something that is incomparable with the later release?

[Luke 43161]

If you can get it to happen again with debug logging enabled then that may tell us more.

[vaise 342]

As to what happens when it stops working, the first time, I got calls from a few friends, but as I was away, I just did a remote restart.

The second time I was watching it myself and just got the spinning disk, and then calls from others, and EVEN the Emby console was not responding - refresh in the browser and timeouts.  I again restarted the docker container and all good again.

I just checked the jellyseer logs and it is going to do a full Emby sync in 15 hours - I will be in bed then.  I don't think it's that as it runs every 24 hours and this issue was at 7:10PM.

To rule it out however, I just kicked off a manual full Emby sync.  Checked Emby logs and processes - no impact and little log activity.

With regards to external access - I have check log files for the same timeframe for jellystat, seerr, Nothing else does any sort of sync.  My API keys are thus - 

Any idea what order, or what below may be the culprit for removal from the plugins - 

 

[vaise 342]

FYI - I am happy to kill all api keys and reset those apps, plus I am happy to kill all manually added plugins for a fresh system, I was just looking at an order of which is more likely to be the culprit.

[vaise 342]

I have started re-assessing plugin needs anyway - first one autobox sets - failure - so that is being removed - 

[Luke 43161]

I think a debug log is the best next step.

[vaise 342]

How would I manage to get that happening, when I don't know when this may occur next ?

[vaise 342]

Same thing happened tonight, and 24 hours later - also around 7PM.  Checked logs.  Different stuff.  Lots of covert processing - I have deleted that plugin.  Will pay close attention tomorrow at the same time. 

[ebr 16817]

14 hours ago, vaise said:

first one autobox sets

This has been defunct for years.

You have a lot of plugins that interact with your system.  You may need to start by removing all those ones you showed in your API key list and seeing if the problem occurs.  Then add back one at a time.

[vaise 342]

9 hours ago, ebr said:

This has been defunct for years.

You have a lot of plugins that interact with your system.  You may need to start by removing all those ones you showed in your API key list and seeing if the problem occurs.  Then add back one at a time.

Yep - today, I only have jellyseer left, and removed a few plugins.

[vaise 342]

Just an update - no failure yesterday.

Working through adding stuff back.

As I checked the dates and logs of the third party apps, I don't think it was them, so started back jellystat, are-dashboard, jellyseer, homepage.

Just the Emby plugins removed so far.

Will monitor today.

[vaise 342]

No issue yesterday - covert the only thing removed.  (and that broken box set one) - Will leave it a few days, then add cover art back and see what happens.

[vaise 342]

No issues still - so the covert I am assuming ws the issue.

When I get a quiet time, I may re-install it.

 

[vaise 342]

I have something new to report.

I have had two more lockups.  

With the assistance of AI, I have tracked these down to Out of memory issues in Unraid docker for ember, but these are NOT restarting the container when it happens - they just stop dead.

These are the two dates and times (one was last night).

/var/log/syslog.1:Sep 25 20:24:23 Tower kernel: .NET TP Worker invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
/var/log/syslog.2:Sep 22 14:28:32 Tower kernel: .NET TP Worker invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

It explains why the logs just stop dead - as emby has stopped dead itself.

AI suggests this - but I take it with a grain of salt -

'Because Emby runs inside a .NET environment (.NET TP Worker), a recent update to the production release has caused either an aggressive memory leak or a massive spike in memory consumption during heavy tasks (like library scans or transcoding), triggering the host's OOM killer. When the host kernel steps in to kill a process like this, Docker often doesn't recognise it as a "clean" container exit and fails to automatically restart it.

As I said before, I have had  very stable system for many years.

I am leaning towards a few drastic possible solutions here - I increased the container RAM after the one on 22/9.  To 16GB which is very high for a container.

I have a GPU doing the transcoding, but I replace any media that seems to be transcoding.

I am thinking of going back to shipped - I have been using emby since the early years and I must have installed and removed loads of things in that time and something must be left behind that may be incompatible with this later version ?

I am thinking of doing this - 

Remove emby beta from my backup server, delete the emby system folders, install emby prod. Compare any settings to the prod system, Recreate the libraries, then read media (all info files).  Restore the users and watch lists from the prod system - Verify.

If all goes well - 

Emby prod outage, Repeat the exact same process above on the prod system, and restore the users/watch list from he backup server. 

No plugins will be installed, only notifications from Sonarr/radarr to refresh the library will be installed.

Run for a while, if no issues after a while, add the link seerr container to the system via an API.