JohnDoee / autotorrent

Matches torrents with files and gets them seeded
MIT License
269 stars 34 forks source link

Handle in-progress matches #18

Closed bitdrip closed 6 years ago

bitdrip commented 6 years ago

I think it'd be great if this program had a way to handle matches that are in-progress. Currently it would be up to the user to realize that a match would be found if only the in-progress download were finished, then it's up to them to retry it once it's finished.

Imagine a scenario where a match is found by file name(s) but not by size because it's in-progress. It would be amazing if instead of outright not matching, it were somehow queued to be added once the download did finish (perhaps pending a re-check that it still is a match).

EDIT: At the very least it would be extremely useful if autotorrent at least notified the user of this, i.e. that a torrent would match once an in-progress download completed, then users can handle that however they see fit.

One way to do that would be to poll rtorrent at intervals to determine when the download finishes, requiring auto-torrent to remain running in the meantime.

Another more sophisticated way might be to register some kind of on_finished event handler/method with rtorrent. I'm not sure if it's possible to specify handlers per-torrent, maybe they're only global, but in that case it can be registered so that it only executes if the infohash matches the in-progress/waited-upon torrent with something like:

# register a global on_finished handler which says:
# if the finished download's infohash matches the one we're waiting on, load its cross-seed
`branch=equal=$d.get_hash=,HARDCODEDHASH,\"load=path/to.torrent\"

I'm not sure if equal= is a method, this is just a rough sketch of what can probably be done. So again, a partial match would be found (file name but size < target_size, we'd then get the infohash corresponding to that download and register that handler on_finished. We'd come to know the infohash corresponding to that match by getting the rtorrent state at launch with a d.multicall, fetching the infohash, the download's directory/path, etc. Then we'd join the match on the directory/path to arrive at the infohash of the match.

EDIT: Added note above.

JohnDoee commented 6 years ago

One thing missing is why you actually want to achieve this but my guess is that you download from Site A and want to automatically seed it on Site B when the torrent is completely downloaded ?

bitdrip commented 6 years ago

On a slow connection with a big torrent it'd be nice to be able to just have it happen automatically when it's done rather than waiting and remembering when it's done so that the 'proper' match could be made.

JohnDoee commented 6 years ago

Executing on complete is a good idea but your solution seems overly complicated to me. It seems to optimize on a parameter that is not actually slow, matching torrents with data.

The easy way is to just combine it with another on-finish application that sorts your completed data, e.g.

That's basically how I run it myself. Autotorrent should be fast enough to just run every time you think there's something new to do.

My problem is that I don't understand your flow, I think. It seems like you are doing part of the process manually, something I don't think you should. Everything should be automatic if possible.

If you want to do part of the process manually, the only part should be "put torrent in a folder" and then your system should figure out the rest. This would be very simple to setup and is something that could just be turned into a small tutorial.

bitdrip commented 6 years ago

Yeah I think you're right, now that I think about it. Thanks for the ideas.