Make parsing size from torrent file the one way to do it

[thebigmunch]

Currently, some trackers announce a human-readable size of a torrent's data. Most simply download the torrent to /temp and parse the size from that. Parsing from announce strings can cause problems and confusion due to inconsistent/improper unit usage. It's also entirely unnecessary.

So, to make the code simpler, I've decided to remove all things related to capturing torrent size strings from announces in favor of just parsing it from the torrent file for all trackers.

[l3uddz]

Could this not be optional? If no torrent size is parsed from the announcement, then fall back to parsing the size from the torrent file itself. Otherwise if it has been provided, use that method?

Making this a standard forces increased load on all trackers (torrent file requests for every filter that uses a min/max size or TorrentSize macro), even if they have made adjustments to provide this information to autodl (such as including file size in bytes in the announcement).

E.g. If size could not be determined via the announcement, fall back to parsing it from the torrent file itself. If it has been provided and parsed correctly, don't request the torrent file.

[thebigmunch]

Making this a standard forces increased load on all trackers (torrent file requests for every filter that uses a min/max size or TorrentSize macro), even if they have made adjustments to provide this information to autodl (such as including file size in bytes in the announcement).

It shouldn't have any noticeable impact if people are not abusing the tracker (i.e. farming buffer/ratio instead of just downloading things they actually want). In that case, buffer farming is the problem, not torrent size parsing. So, I'd say that if a tracker wanted to reduce load, they should crack down on farmers.

E.g. If size could not be determined via the announcement, fall back to parsing it from the torrent file itself. If it has been provided and parsed correctly, don't request the torrent file.

That's how it was. That's not how it is now. It's not going to be changed back without some compelling argument that I didn't already consider before making the decision.

[l3uddz]

Take this script for example: https://paste.ee/p/SjhHX

It passes the relevant information along to sonarr and radarr for it to decide if it wants to grab the release. If it does, sonarr/radarr send the releases directly to rutorrent. Autodl is used as an instant RSS in effect based on the announcement messages. This means a ton of torrents are downloaded to determine the file size (correct me if I'm wrong) for lots of stuff that is ultimately rejected.

I have been speaking to the ptp dev and he has shown interest in adding the bytes size to announcement messages r.e. the outcome of this issue.

Maybe there is another way of doing this that does not involve grabbing every release torrent to determine file size?

[thebigmunch]

Take this script for example: https://paste.ee/p/SjhHX

It passes the relevant information along to sonarr and radarr for it to decide if it wants to grab the release. If it does, sonarr/radarr send the releases directly to rutorrent. Autodl is used as an instant RSS in effect based on the announcement messages. This means a ton of torrents are downloaded to determine the file size (correct me if I'm wrong) for lots of stuff that is ultimately rejected.

That's great. But I'm not responsible for how people try to paste autodl together with other software. It is (or should be) only an issue when people actually care about the data size. It's my experience that people mostly either don't care about the size because they know they want a specific format (information easily provided in an announce) or use a size range so large as to not actually be useful. The common case outside of those is wanting episodes rather than season packs or vice versa. This is easily solved by providing that information in the announce in some way (e.g. BTN).

In the case of PtP, they already provide encoder, source, container, resolution, and scene in their announce. What valid reasons are there for anyone to even need filtering by size with all that information provided?

[l3uddz]

I don't see how requesting every announced torrent when they have already supplied the file size in the announcement is not a problem? (even if the intention is just to check it meets the filters size requirements)

This is terribly inefficient for both parties involved.

While your argument that it is not often used because people prefer specific formats or encoders is true, there will always be fringe cases where file size is relevant (e.g. skip future releases by a new group that pops up that mimics yify, or skip full disk rips that are named incorrectly, e.g. no complete in the title)

[thebigmunch]

I don't see how requesting every torrent when they have already supplied the file size in the announcement is not a problem?

What you can (or, more aptly, choose) to see doesn't really factor into my decision.

This is terribly inefficient for both parties involved.

But you've provided no evidence of this. Nor any situations where this would possibly hold true based solely on the torrent size filter option. Given two filters with identical options aside from one setting torrent size options, they will both download the same number of torrents. Only the one with the size set would waste anything on the tracker's end. And this would only be wasteful when it actually rejects something based on the size. And this would only add significant load when someone is doing something abusive or unsupported.

So, again, if you can come up with situations that the torrent size option itself adds significant load to trackers, you can come to IRC or Discord to present your evidence. Until then, this issue is closed and will be locked.