Possible cross-seed integration?

[mmgoodnow]

I'd love to have an easy integration with autotorrent2. Some way for cross-seed users to be able to leverage autotorrent2's advanced injection capabilities in a fully-automatic way would be terrific.

Here's what I'm thinking:

POST /add-cross-seed
Content-Type: application/json
{
  "filepath": "/path/to/torrent/file.torrent"
}

From there, autotorrent's rules would automatically triage the torrent into the right place.

@JohnDoee what do you think?

[JohnDoee]

I'm all for it!

There are a few ways we can do this depending on how visible Autotorrent should be. I'm not sure what would be best.

In these example I'll just use commandline execution of Autotorrent as way to inject into Autotorrent. I can do a simple daemon mode if needed but we can cover that later.

Autotorrent fully hidden
The user puts autotorrent2.exe in a folder and cross-seed execute it in configless mode that might look something like autotorrent2.exe add-configless /path/to/linkfolder deluge://127.0.0.1 /path/to/ubuntu.torrent

The torrent will be added using Autotorrent logic but the user will not really see it.

This method does not exist yet but should be easy to add.

Autotorrent somewhat hidden
The user installs autotorrent as normal and configures it like normal. When cross-seed needs to inject a torrent it runs the correct commands that a user would normally run themselves

autotorrent2.exe scan -p /path/to/matched/data
autotorrent2.exe add torrent-client ubuntu.torrent

This is how I use autotorrent2 in my own setup, when new data is downloaded, I scan it and just match with other torrents I downloaded.

It'll require knowing where the expected matched data is but you already do.

Autotorrent is just executed
This is the most simple mode and would not actually need to be specific for autotorrent. Instead of injecting the torrent a commandline command is just executed by cross-seed. In cross-seed the user configures something like execute_command=autotorrent2.exe add torrent-client %TorrentPath%

The omen of scanning the data is also on the user here.

Conclusion

I don't have any preferred way and I'm not actually really sure what would be best. The first way will make cross-seed an integrated experience while the third way will put the power in the hand of the user.

[JohnDoee]

The reason I've not dockerized is that I fear people will screw up badly with path alignment, imagine adding 500 torrents to qbittorrent that all start downloading instead of seeding.

Not sure if there are any other solutions than tell people it's their own problem though, although I handed them the foot-gun.

[mmgoodnow]

Not sure if there are any other

It would be possible to verify the contents before injecting the torrent into the client. For rtorrent, as I'm sure you're aware, this is required for fast resume to work.

[JohnDoee]

The problem is when path mappings are not the same within docker containers. I'm not sure how common it is to make it different within different docker containers though.

e.g.
rtorrent has /data/
autotorrent docker container has /mnt/data/

[Jerrk]

If that is an issue then perhaps you can add an option for "remote path mappings" like the arr apps are using?

[mmgoodnow]

imagine adding 500 torrents to qbittorrent that all start downloading instead of seeding

Verifying contents would prevent the quoted issue. Yes, it's still a big source of confusion, but it would protect the user from hurting themselves.