Sonarr can't download from Prowlarr indexer: "invalid torrent file specified"

guss77 · March 16, 2022, 11:28pm

Sonarr version (exact version): 3.0.7.1477
Mono version (if Sonarr is not running on Windows): 5.20.1.34
OS: Ubuntu
Debug logs: enabled
Description of issue: I have set up Prowlarr and Sonarr. Searching works fine but when I try to download Sonarr shows a red cloud icon and the tooltip says “invalid torrent file specified”.

The logs have this to say:

—8<—
Mar 17 01:04:40 normandi docker[775709]: [Warn] ProcessDownloadDecisions: Couldn’t add report to download queue. Some.Series.S00E00.video
Mar 17 01:04:40 normandi docker[775709]: [v3.0.7.1477] MonoTorrent.TorrentException: Invalid torrent file specified —> MonoTorrent.BEncoding.BEncodingException: Invalid data found. Aborting
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.BEncoding.BEncodeDecoder.DecodeTorrent (MonoTorrent.BEncoding.RawReader reader) [0x0001a] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.BEncoding.BEncodedDictionary.DecodeTorrent (MonoTorrent.BEncoding.RawReader reader) [0x00000] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.BEncoding.BEncodedDictionary.DecodeTorrent (System.IO.Stream s) [0x00006] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.Torrent.Load (System.IO.Stream stream, System.String path) [0x0000c] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: — End of inner exception stack trace —
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.Torrent.Load (System.IO.Stream stream, System.String path) [0x00033] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: at MonoTorrent.Torrent.Load (System.Byte[] data) [0x0000d] in <4a57d41ab7c745b0971575485f9e1359>:0
Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.MediaFiles.TorrentInfo.TorrentFileInfoReader.GetHashFromTorrentFile (System.Byte[] fileContents) [0x00000] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\MediaFiles\TorrentInfo\TorrentFileInfoReader.cs:14
Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.Download.TorrentClientBase1[TSettings].DownloadFromWebUrl (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode, System.String torrentUrl) [0x00223] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\TorrentClientBase.cs:189 Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.Download.TorrentClientBase1[TSettings].DownloadFromWebUrl (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode, System.String torrentUrl) [0x000cc] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\TorrentClientBase.cs:152
Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.Download.TorrentClientBase1[TSettings].Download (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode) [0x00148] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\TorrentClientBase.cs:117 Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.Download.DownloadService.DownloadReport (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode) [0x0019f] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\DownloadService.cs:75 Mar 17 01:04:40 normandi docker[775709]: at NzbDrone.Core.Download.ProcessDownloadDecisions.ProcessDecisions (System.Collections.Generic.List1[T] decisions) [0x00104] in M:\BuildAgent\work\63739567f01dbcc2\src\NzbDrone.Core\Download\ProcessDownloadDecisions.cs:77
—8<—

I think the problem is that Sonarr interacts badly with the way Prowlar shares magnet download URLs - looking at the HTTP logs for the Prowlarr reverse proxy, I see things like this (after clicking the download button in Sonarr):

—8<----
172.17.0.6 - - [17/Mar/2022:01:04:32 +0200] “GET /51/download?apikey=XXXX&link=VERYLONGTEXT&file=Some.Series.S00E00.video HTTP/1.1” 301 4104 “-” “Sonarr/3.0.7.1477 (ubuntu 18.04)”
172.17.0.6 - - [17/Mar/2022:01:04:32 +0200] “GET /?apikey=XXXX&link=VERYLONGTEXT&file=Some.Series.S00E00.video HTTP/1.1” 200 6198 “-” “Sonarr/3.0.7.1477 (ubuntu 18.04)”
—8<----

The first request is what Prowlarr expects - its in the Prowlarr search results RSS (I did a network dump to verify), and when Sonarr calls that, it gets a 301 permanent redirect. Here’s me manually running the query:

—8<—
$ curl -D- ‘https://my.server/51/download?apikey=XXXX&link=VERYLONGTEXT&file=Some.Series.S00E00.video’
HTTP/1.1 301 Moved Permanently
Date: Wed, 16 Mar 2022 23:01:24 GMT
Server: Kestrel
Content-Length: 0
Cache-Control: max-age=31536000, public
Last-Modified: Mon, 31 Jan 2022 18:22:22 GMT
Location: magnet:?xt=urn:…
X-ApplicationVersion: 0.2.0.1448
—8<—

So it looks like after Sonarr gets the 301 response, instead of using the magnet URL in the Location header, it re-issues the request with a path of / (instead of the Prowlarr provided indexer download path), which Prowlarr obviously responds with something that is not a torrent file.

I’m not sure if Prowlarr is set up properly - I don’t think its supposed to send a redirect to a magnet link, but I can’t find where to configure it not to do so: all the indexers have a setting for “Redirect” that seems appropriate - it says that when disabled Prowlarr will proxy the content from the indexer instead of sending a redirect to the indexer - but this checkbox is unchecked and actually disabled in all my indexer, it cannot be turned on.

Though I’m pretty sure Sonarr is at fault here - no way the correct handling of a 301 to a magnet URL is to call the root path on the HTTP server.

I’m pretty sure its a recent change in Prowlarr (I have an auto update using linuxserver’s docker image), as right now Radarr can’t download from Prowlarr with the exact same behavior.

bakerboy448 · March 17, 2022, 1:50am

That option is only needed for a small handful of newznab indexers and also for if one add’s jackett as torznab in Prowlarr for a tracker that responds with magnet links.

Your issue is likely neither Radarr nor Sonarr nor Prowlarr, but an incorrectly configured reverse proxy
https://wiki.servarr.com/prowlarr/installation#nginx.

Also the *arrs and prowlarr should not be talking to each other via a reverse proxy if they’re all local or can otherwise talk via the LAN - it’s not needed, not best practice, adds a single point of failure, and adds a lot more complication that is easy to screw up. it’s like going outside your door to go in the back door to go in the kitchen…because you don’t want to just go through the hallway

guss77 · March 17, 2022, 4:48am

I have reviewed the reverse proxy configuration, and host and forwarding headers are set correctly - if they weren’t, Sonarr wouldn’t have gotten a usable download URL from the search results.

guss77 · March 17, 2022, 11:48am

Here are the relevant logs from the trace log (now that I found where it is):

[v3.0.7.1477] MonoTorrent.TorrentException: Invalid torrent file specified —> MonoTorrent.BEncoding.BEncodingException: Invalid data found. Aborting
…
—8<—

I looked at (what I think is) the relevant source code at https://github.com/Sonarr/Sonarr/blob/0a2b109a3fe101e260b623d0768240ef8b7a47ae/src/NzbDrone.Core/Download/TorrentClientBase.cs#L44 , and that looks to be correct - it would get a web download URL from Prowlarr, call DownloadFromWebUrl(), which gets a permanent redirect to a ‘magent:’ URL, and then should trigger DownloadFromMagnetUrl().

But from the logs it looks that response.Headers.GetSingleValue("Location"); contains something that is different than what I’m getting when I run the download URL request through curl.

guss77 · March 17, 2022, 4:38pm

I found the problem and it is indeed a problem with the Prowlarr reverse proxy configuration:

I’m using Apache with a Lets Encrypt configuration as a reverse proxy, and Prowlarr relies on the X-Forwarded-Proto header to generate the correct schema in the search results RSS. The configuration from the Prowlarr documentation has the correct setup to enable this header in Nginx, but not in Apache. When Sonarr tried to access the download URL through http:// instead of https:// it encountered the HTTPS redirect that Lets Encrypt’s certbot sets up, which redirects to the HTTPS server without retaining the URL path - which is also likely not correct.

After adding the following configuration to the Apache reverse proxy setup, the problem was gone:

RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}

(this required enabling mod_header that wasn’t enabled by default on my setup).

I’ve also fixed the HTTP configuration’s redirect rule to retain the URL path, which would have likely fixed the problem as well, but I didn’t test that.

system · May 16, 2022, 4:38pm

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.