Constant timeouts from api4.thetvdb.com

[nomad2go 2]

I'm seeing these errors non-stop in my logs. From the linux server I can use curl or wget against the URL and I get a response, so I am positive it is not a firewall issue. I've also tried disabling the firewall (ufw) entirely and it makes no difference. I recently moved (geographically) which meant my server was down for a couple of days and when I brought it back most or all of my metadata/artwork was missing. Maybe it's possible thetvdb.com is throttling me because I'm hitting their servers too much, but I'm not sure how to check for that. Can anyone help?

My logs are *flooded* with these errors:

024-04-20 17:43:43.206 Error App: Error in TheTVDB
    *** Error Report ***
    Version: 4.8.3.0
    Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
    Operating system: Linux version 5.15.0-100-generic (buildd@lcy02-amd64-014) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #110~20.0
    Framework: .NET 6.0.25
    OS/Process: x64/x64
    Runtime: opt/emby-server/system/System.Private.CoreLib.dll
    Processor count: 24
    Data path: /var/lib/emby
    Application path: /opt/emby-server/system
    MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: Cancelling connection to https://api4.thetvdb.com/v4/series/421807/episodes/official?page=0 due to a previous timeout.
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.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.TvdbEpisodeProvider.GetEpisodeData(EpisodeInfo searchInfo, Boolean fillExtendedInfo, IDirectoryService directoryService, CancellationToken cancellationToken)
       at Tvdb.TvdbEpisodeProvider.GetMetadata(RemoteMetadataFetchOptions`1 options, CancellationToken cancellationToken)
       at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken)
    Source: Emby.Server.Implementations
    TargetSite: Void MoveNext()
   

[nomad2go 2]

Also, my library scan is taking forever; it's been days now. I'm not sure if that's because of these errors and an inability to pull metadata/artwork... or because I changed a few things - made sure all artwork was being saved alongside media (which it already had been but I then did a full refresh so it's possible I had stuff in the cache prior) and added the "skip intro" feature, which I know will take some time. I also have a large library. Would be nice to solve this timeout problem though either way. Does anyone have any ideas? How can I further diagnose? Thank you!

Edited April 20 by nomad2go

[nomad2go 2]

Seeing the same thing for TheMovieDB...

2024-04-20 22:08:51.775 Error App: Error in TheMovieDb
    *** Error Report ***
    Version: 4.8.3.0
    Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
    Operating system: Linux version 5.15.0-100-generic (buildd@lcy02-amd64-014) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #110~20.0
    Framework: .NET 6.0.25
    OS/Process: x64/x64
    Runtime: opt/emby-server/system/System.Private.CoreLib.dll
    Processor count: 24
    Data path: /var/lib/emby
    Application path: /opt/emby-server/system
    MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: Cancelling connection to https://api.themoviedb.org/3/tv/105/season/3/episode/14?api_key=x_secret1_x&append_to_response=images,external_ids,credits,videos&language=en-US&include_image_language=en-US,en,null,en due to a previous timeout.
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
       at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod)
       at MovieDb.MovieDbProviderBase.GetMovieDbResponse(HttpRequestOptions options)
       at MovieDb.MovieDbProviderBase.FetchMainResult(String urlPattern, String id, Int32 seasonNumber, Int32 episodeNumber, String language, String country, CancellationToken cancellationToken)
       at MovieDb.MovieDbProviderBase.DownloadEpisodeInfo(String id, Int32 seasonNumber, Int32 episodeNumber, String preferredMetadataLanguage, String preferredMetadataCountry, String dataFilePath, CancellationToken cancellationToken)
       at MovieDb.MovieDbProviderBase.GetEpisodeInfo(String tmdbId, Int32 seasonNumber, Int32 episodeNumber, String language, String preferredMetadataCountry, IDirectoryService directoryService, CancellationToken cancellationToken)
       at MovieDb.MovieDbEpisodeProvider.GetMetadata(RemoteMetadataFetchOptions`1 options, CancellationToken cancellationToken)
       at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken)
    Source: Emby.Server.Implementations
    TargetSite: Void MoveNext()
   

[Happy2Play 8296]

On 3/18/2024 at 8:48 PM, Luke said:

HI, typical causes of the timeouts are firewall, security software, or VPN. Can you look into those and let us know what you find? Thanks.

  May need to see complete server log but these issues are usually specific to your network.

[nomad2go 2]

What's the best way to upload a full log? They're getting pretty huge. Should I roll one over in Scheduled Tasks and then grab embyserver.txt after a couple minutes or is there additional logging I need to enable or anything else I need to do? Thank you for the response!

Edited April 21 by nomad2go

[Happy2Play 8296]

In the end devs will look at what sites you are timing out to but if it is everything then it is something specific in your setup.

If no vpn then maybe IPv6 as that has been and issues also in other topics.

Rollover logs usually do not show comunication with admin server.

[nomad2go 2]

Got it. I'll try to look into it some more.

I just noticed that I'm able to edit the images for a movie or show manually and both see and select artwork from TheTVDB or TheMovieDB... How does that make sense? Looking at the logs, it seems when I'm grabbing the image manually it's coming from artworks.thetvdb.com instead of api4.thetvdb.com. So, I guess that's why it makes sense. Interesting I can get to artworks.* but not api4.*...

I also get a response immediately when I run curl from the Emby server...

curl -i api4.thetvdb.com
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=UTF-8
Content-Length: 24
Connection: keep-alive
Date: Sun, 21 Apr 2024 03:28:09 GMT
Vary: Origin
Vary: Accept-Encoding
X-Cache: Error from cloudfront
Via: 1.1 2b2491fc3c8b84a7fd8dd41a09ba5510.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: BOS50-P4
X-Amz-Cf-Id: 9YdaDdskQSi4BHNgzp23mpeYPD-ZpMT3Z1UU5umaorY8dkGC6akxyg==

{"message":"Not Found"}

[Luke 37107]

Hi, are you using a VPN?

[nomad2go 2]

No, no VPN.

[Luke 37107]

Can you think of anything on the server machine that could be preventing Emby Server from sending these outgoing requests?

[nomad2go 2]

No, I can't. The only new idea I had was to search the logs and see if I could identify the point in time at which the problem began. And it did seem like it started on 4/17 and may not have been happening prior to that. So, that got me thinking. Late at night on 4/16, I rebooted the system and booted into an older grub profile because I was encountering this problem (below), where SMB shares stopped working on the latest update for the Ubuntu kernel 22.04.

 

(And further detail here) - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780

Booting into the older kernel addressed the problem with accessing the shares but it was apparently then that the problem with the timeouts began.

Anyway, I rebooted the Emby server as it also showed updates were available and, after that, it looked like the problem went away. Emby was able to connect to the APIs fine. I was about to come and post here about it but wanted to let it run for a bit to be sure. Unfortunately, due to another (unrelated) problem, my NAS basically just died... So... I haven't been able to 100% confirm that the problem is gone because I have Emby and the NAS both shut down but I'm pretty sure it is...

Now I need to go figure out why my Synology NAS has the blue blinking light of death. Thank you for replying to me. Hopefully I've been able to be helpful to the forum in some way. Maybe other Linux users are experiencing the Samba share problem... That was a major PITA to track down and diagnose.

[nomad2go 2]

Actually, I got the NAS recovered... I'll start up Emby shortly and report back if I find anything further. Thank you.

[nomad2go 2]

Yup... the problem resolved itself. I'm not sure how or why it happened but either the restart or the upgrade to the latest version of Emby fixed it for me.