Hello all, I am wondering if a torrent’s “Info Hash” is used in series/episode searches?
The situation I am encountering is that I am finding multiple versions of TV show episodes. When I find one that I like as far as size and quality, I would like to maintain the consistency of those metrics across all the episodes in the series.
One method already employed to address this issue is the use of tags. Of course, there is no way to include tags for a torrent’s info hash. Especially, since there is no way of knowing the info hash of the torrent you want ahead of time. But tags are used to whittle down a query result from several dozen to 6 or 7. This effect can been seen in manual searches. While it would be nice to have the results that aren’t a match filtered from the list, I understand they’re there to help fine tune the development of accurate tags.
This is where I think the info hashes could help. If the info hash of those 6 or 7 torrents were used to filter or even perform secondary search the list could be shortened pretty accurately. If you do a google search on a info hash its extremely accurate for finding the exact same torrent across every single torrent site that has that torrent. In fact, it could help in finding additional indexers that aren’t currently configured.
No, that’s not known until the result comes back in the searches.
You’d have to go out and find the hash then add it to restrictions, at that point you’re better off just manually sending it to your client and labeling it appropriately.
That’s not something Sonarr is concerned with, if you want to find other sites you’ll have to do that outside of Sonarr.
Are you sure that I’d have to go out and retrieve the info hash?
I was thinking, after a scheduled auto-search, when torrents are found that match all criteria/tags/etc., the info hash could be picked up along with all the other vital information about the torrents. Then, before the results are actually displayed in the UI (or at the same time ), another search could be done (using the info hash) showing other sites that have that torrent… much like the instant search that occurs here when you post a topic and as you type it shows other theeads that match the topic you’re posting about.
Since one if the objectives of Sonarr appears to be automation I would consider this to be inclusive.
Before you could filter in it, absolutely, it’s unique per torrent after all.
That’s not what Sonarr is for… and there is no advantage to showing more sites with the same info hash, it’d just be more of the exact same thing in the UI and a waste of time waiting for searches, plus Sonarr doesn’t parse HTML to filter search results.
Sure, automating managing of TV shows, not automating finding other indexers (plus without an API or at least an RSS feed they’re worthless to Sonarr). This is definitely outside the scope of what Sonarr does and I’m not really seeing an advantage to doing something like this.
But I’m not talking about before initial query results are returned. I’m talking about after but before they’re displayed in the UI. I understand that there is no way to know the info hashes beforehand. I’ve said this three times now.
It may not be what Sonarr is for but Sonarr is already doing it. A manual search for shows in my library produce results that are from different indexers. Some of the results are for the exact same torrent. Only, they don’t appear identical because besides being on different indexers they also have a different number of seeders/peers. So having a torrent listed more than once offers a distinct advantage. If a torrent fails, it can be replaced by a torrent from a different indexer. Info hashes offer a way to confirm you have the same torrent. [As alternative, you could find a way to validate the seeder/peers]
Granted, all this is among pre-configured indexers. Since Sonarr is not currently capable of searching sources not configured on the indexer page of its settings I will concede that attempting to do so would be outside the scope although I couldn’t find anything to preclude that on Sonarr’s github feature list.
The advantage I could see would be to produce more accurate search results or to filter results more accurately
As it stands, I see about a dozen dead torrents in my torrent client. These torrents were passed to the client by Sonarr. Yet, they sit idle with 0 filesize, seeders, and peers. This results in my having to perform a manual search for the episode from the series page within the Sonarr UI and then find the exact same torrent on another indexer with more seeders/peers. Then I click download icon to have the torrent passed to the client, downloaded and I move on to the next one. This process that I have to do is completely in scope. I am manually search existing, pre-configured indexers for a series episode using pre-determined criteria and pass them to a download client. That is in scope because that is what Sonarr is doing already. The difference is that I know a torrent died in the torrent client and Sonarr doesn’t.
I don’t have unreal expectations. I don’t expect including info hashes to eliminate the issue 100%. If there are a dozen or so ‘dead’ torrents in a client passed to it by Sonarr, I would be happy to reduce that number by 4.
Largely irrelevant to the discussion, but I have to mention that has absolutely nothing to do with an Info Hash. Since an Info Hash is about a specific release, and does not say anything about different episodes in the same series.
First, are you sure these are the exact same torrent and not just the same name?
If I read that correctly, you’re not asking us for ‘Info Hash search’, you’re asking us to combine the available trackers from multiple torrents if the infohash happens to match, so that other trackers can be used to download the same torrent, reducing the risk of having no seeds.
The issue with your posts so far is that you’ve been trying to describe a solution instead of a problem. (It’s a trap that many of our users fall in.)
Especially your original post is confusing since it doesn’t even mention hitting zero seeds.
If my assumptions about your real intentions are true, then what you’re describing is what we call ‘Failed Download Handling’: The actions that Sonarr needs to take if one if the initiated downloads fails to complete. For usenet downloads we simple search for alternative downloads. But for torrents we do nothing, this is largely due to potential complications with private trackers, which is the primary type of trackers Sonarr supports. Thus the related github issue is still open and pretty old.
For your specific problem I’m wondering if you have DHT enabled, since that would pull in peers outside of the limited list of trackers.
Here is why I believe it to be relevant: If I have 100 episodes. All ~300mb, x265 & have other unique details that I find suitable, I want other episodes of the same metrics. If I find one, but the download fails for whatever reason…or at least for reasons related to availability [seeders/peers],… I want to be able to search for that exact torrent elsewhere. I would like to be able to search for that specific torrent without going through the entire search list again.
I’m sure because when I see a failed torrent [size: 0, seeders/peers: 0/0] I take its info hash to google to find other sites that have that torrent and then try to add that site to the indexer setting page or to Jacket. I’m not always successful in finding a new indexer. Some of the times when I fail to find a new indexer it is because the indexer already exists in Sonarr or Jackett
I am sorry for the confusion of my initial post. I posted here cuz I thought this is feature request and not troubleshooting. Zero [seeders/peers] is definitely a problem but I have the manual solution described above.
As a feature request I felt the feature would help more than just my specific situation [by changing the process from manual to automatic], but also aid in the finding of additional indexers which I’m also doing manually right now. It is also an aid to filtering torrent search results. Tags work fine. Info hashes would help them further. These points were all mentioned in the initial post. The zero seeder/peers was just a symptom of one of those points. If finding additional indexers is out of scope, that’s fine. It may still help with the other aspects. All that to say, this isn’t as much a solution without a problem. It’s a feature request.
You have certain criteria that you want a download to conform to. Primarily size and codec, but other unnamed criteria well.
Some of these criteria can be configured in Sonarr, but some cannot, therefore you search manually in Sonarr for suitable releases.
When finding suitable releases, you often encounter the issue that said download fails due to having too few peers.
Searching manually again in Sonarr is cumbersome, especially because you believe that other releases exist that match the same criteria. And you propose info_hash as means to do identify those, since it’s guaranteed to point to the same content.
By experimentation you’ve discovered that such alternative releases sometimes have sufficient seeds to complete the original download.
Additionally you propose that Sonarr automatically searches other unknown indexers (via google?) for the same torrent to further improve the chances of completing the download.
If anything is missing from that list, please say so now.
So, from that list I identify a few problems:
You have criteria that you cannot properly configure in Sonarr, and therefore Sonarr cannot automate downloads, meaning you have to resort to manual selection. How big of an issue is that? Compared, for example, to the zero seeds.
You can limit the sizes that Sonarr accepts for releases, you can also tag series to require specific keywords such as x265. In the future it’ll be possible to prioritize certain keywords, instead of making them required. I’d like to know what other criteria are missing. It might not be relevant if it’s not a big issue, but it seems to be at the root of your problem.
Downloads cannot be completed due to too few peers, despite the fact that other torrents with the same info_hash can. So deal with that you’re seeing for Sonarr to find those alternative torrents automatically. This indicates that your tracker/announce lists are incomplete. I asked it before, but do you have DHT enabled? Secondly, what kind of public trackers are we talking about?
If DHT is disabled or not functioning properly, that could explain the lack of seeds.
Finally your proposed features:
Checking google for torrents with the same info_hash. This isn’t something we’re going to consider. Sonarr only works with the configured indexers and we’re not going to implement something that does random google searches or similar.
‘Googling’ might not be specifically what you asked, but I wanted to be clear about it.
Using info_hash to find multiple torrents/releases with the same data. I’m not opposed to something that incorporates the info_hash but has a few complications and imho has a fairly limited usecase if DHT is used.
First, the configured indexers MUST return the info_hash, otherwise we’d have to download each .torrent to check the info_hash, so any feature would be limited to indexers that return the info_hash.
Secondly, I’m not entirely happy with downloading multiple .torrent before hand to aggregate the announcelist. Some indexers include extra announces in the .torrent url, aggregating those might be quite feasible. Finally, afaik Jackett hides the original url, which would prevent any of this from working.
Considering all that, I feel like a feature like this would be fairly limited in usefulness.
To circle back to the beginning:
You should check if DHT works properly in your torrent client. With a properly working DHT, you really shouldn’t have to google the info_hash, coz the DHT distributes peers globally based on info_hash.
Let us know what additional criteria you use to select releases. At the very least we should be able to tell you if we have plans to incorporate such criteria in the future.
Please keep in mind that as a feature request, it should not be all about me. So while I will answer your questions with details that are specific to me, my hope is that this feature would be helpful to similar situation that others may have even though their details and situation may be different
Having adjusted expectations my answers in-line …
I’m going to stop here. I think I am not communicating properly. I am aware that I can over-explain things and that is a source of confusion. But I am trying to correct that. Please read my responses above and see if its less confusing? maybe?
If it does, great. Lets discuss further. If not, then lets take a break… Enjoy our holiday weekend and revisit all this later.
Couple other details:
I do manual searches because I have a libary of about 50 tv series. I am not comfortable in handing over the keys to the kingdom completely to Sonarr. If something goes wrong I want to understand the processes that Sonarr goes through so I can troubleshoot. So for now, I am adding TV series one at a time. I am also adding new TV series that catch my attention, one at a time. I am never wrong on multiple shows simultaneously. I want to get through about 5 or 6 without issue before I hand over the other 30-40 TV series to Sonarr
Also, I am using a VPN service and it’s installed on my router so everything leaving my LAN goes through vpn first. Maybe this creates an issue with the DHT you were referring to.
Your replies in the last post are excellent. Notice how you explain exactly HOW you’re using Sonarr and why? This is valuable information.
Since you’ve responded with ‘Yes’ in all but one case, means my interpretation of the situation is improving.
You indicated that the configurable criteria aren’t an issue at all, so I’ll ignore that from now on. Which leaves zero seeds.
I don’t know where these settings are. Or what they should be set to. I know generally that they’re used by torrent clients but that’s the extent of my knowledge.I never changed anything regarding DHT tho. An additional detail is that I am using a vpn which may be problematic
To my knowledge VPN does not interfere with DHT.
DHT = Distributed Hash Table. Consider it a global peer-to-peer network that is used to share metadata such as .torrent files and lists of available peers. The latter is relevant for your particular situation.
(Please note that torrent clients get suitable peers from trackers and DHT.)
Usually torrent clients display the number of connected DHT nodes somewhere in the UI.
I’ll need to know the exact torrent client used to be able to say more about where to find the settings. But googling “{client name} DHT” or “{client name} DHT doesn’t work” might give you some useful hits.
Can you find that particular Korean release again? Not the .torrent, but in Sonarr search results. Why I’m asking is because we need to check if your indexers actually provide info_hash in their query responses.
Secondly, when rejecting a release (like the Korean subs one), do you use the Blacklist function? In Activity->Queue you can ‘delete’ and blacklist an active download. Sonarr then registers the torrent info_hash in the blacklist. And for subsequent manual searches any release with the same info_hash should show up rejected.
couldnt they use the minimum seeders option for this? its only as accurate as the indexers data but it would stop sonarr from selecting a zero seed file, unless the indexer is saying there are seeders when there arent (but thats going to impact manual searches as well)
Normally yes, but OP is manually search for individual episodes in order to get a feel for Sonarr. Meaning he’s already considering the seed info provided to select the right download, and still ends up with zero seeds. So for auto-grabs, yes, you’d be right but it doesn’t play a role in this case.
That would make stuff easier yet insanely boring at the same time.
So, deluge. The DHT Nodes are at the bottom of the status bar on the right, it shows the number of connected nodes. It should be non-zero.
The associated settings are under Preferences->Network. which has ‘Network Extras’ at the bottom with DHT as a checkbox. Disregard the other settings, they’re likely different for you.
]
