Prowlarr
Add `PreferMagnetUrl` to prefer magnet links over torrent file links
Database Migration
NO
Description
This pull request adds the option PreferMagnetUrl. The aim of this option is to ensure that consuming applications will receive magnet links when available, instead of torrent file links. Applications that support Prowlarr (such as Radarr and Sonarr) should already support magnet links, as some providers do not provide torrent file links in the first place (e.g. TPB). This change thus leverages existing implementation for the handling of magnet links, tracking, and so on. Consuming applications should not be aware that Prowlarr may prioritize magnets over torrent file links.
This behavior only works when a magnet link is available for a release. If a magnet link is not available, the torrent file link is provided to applications as normal. Note that avoiding torrent file downloads may alleviate bandwidth and resource usage of the indexer, which could be favorable for said indexers. Additionally, because torrent files are often not downloaded with this option enabled, Prowlarr may avoid throttling or bans on certain indexer download endpoints (e.g. YTS).
The default value is off (retain current behavior).
Screenshot (if UI related)
Settings:
Todos
- [ ] Tests
- [x] Translation Keys (./src/NzbDrone.Core/Localization/Core/en.json)
- [ ] Wiki Updates
Issues Fixed or Closed by this PR
- Might relate to #1799, but this is unverified.
I would love your feedback on the idea itself, but would also like to ask for guidance on the continuation for this PR. Specifically for tests and Wiki updates. What do you think is needed in those areas and how should I approach these? Thank you in advance!
Hey,
Grab history has it's purpose like I explained on discord, so changes removing this functionality are not going to be accepted.
My suggestion would be to use enclosures, application/x-bittorrent for torrent and application/x-bittorrent;x-scheme-handler/magnet for magnet. After implement which one to prefer in Sonarr/Radarr/etc., with an option per indexer most likely. You need to ensure a follow redirect is being used, and in this manner the grab history is still going to be saved.
Understood. I'd like to avoid having to have a PR for both Radarr and Sonarr, so I'll investigate to see if there is a better way before I approach it that way. Thank you for the feedback. I will get back to this.
I took another dive into the codebase and I believe that I found a better way to achieve the initial goal of preferring magnet links over torrent file links. When I was inspecting the situations that could occur and need to be supported, I learned that some indexers do not have torrent file links in the first place (e.g. TPB). That means that consuming applications already need to deal with proxied magnet links to function correctly. After tracing what happened in those situations, I stumbled on the implementation in Radarr and Sonarr to handle proxied magnet links.
Well, it turns out that I was overthinking this feature. My earlier implementation of giving raw magnet links to consuming applications was unnecessary, and breaking tracking was easily avoided. The necessary behavior change is actually dead simple. Just swap the priority of DownloadUrl and MagnetUrl around in the NewznabResults XML builder. So, that's what I did. I have updated the PR details with a new title, description and screenshot to reflect these changes. Did I miss anything?
What do you think of the feature in this new state?
After tracing what happened in those situations, I stumbled on the implementation in Radarr and Sonarr to handle proxied magnet links.
Yes, they do as long it's an enclosure and not as the Torznab MagnetUrl attribute which needs to be unproxied.
This is why I suggested using enclosures and doing the decision in Radarr/Sonarr.
If I would to nitpick, I don't think this should be a global option.
I'll have to discuss this further with the other dev.
Right. Let me know if you want me to change the PR from a global option to an indexer option.
Personally, I like choosing magnet links globally, but I understand the argument for an indexer option as well.
May I ask what the status of this PR is? Should I take steps to keep moving this feature forward?
For context, I spoke with bogdan about the status of this feature ~10 days on Discord.
my main nitpick remains and that I don't think this should be a global option. now that some time has passed I'm 100% sure it should per indexer
I finally got around to it, so that's what I did in the latest set of changes. I moved the PreferMagnetUrl from a global option to a per-indexer option. This change requires a new column in Indexers table, so I added a migration and updated my initial post with the new 'Migration needed' status and updated description & details.
The feature is certainly more versatile this way👍
Hey, I took a jab at your PR and I think it's better to avoid a new db migration if possible.
@bakerboy448 any proof reading on the english translations?
At this point I'm done with the translations, we'll revise in the future depending on how many users will complain about being unclear. 😂
Thanks for the contribution to all involved!