Feature Request: qBittorrent Hardlink Categories

Hello,

Use Case 1 File A is downloaded into a qBittorrent category called “Downloads - ISO” which, with qBittorrent automatic management, points to /downloads/complete/iso/. Currently, the way I understand injection with daemon mode to work, the cross-seeding torrent from another tracker would also be inserted (with default tag cross-seed) into the same category and folder location. This category, or a generic Radarr or Sonarr category, may only be a placeholder category for new incoming files and not match my category organization for longer term storage.

If I move one of the copies of the torrent in the interface, the second copy is now pointing to missing data and I need to manually move that torrent’s category as well. This inhibits my ability to leverage qBittorrent’s automatic torrent management mode to manipulate where data lives on the server.

Use Case 2 Preexisting torrents that are scanned using scan mode instead of daemon mode will do the same behavior as use case 1. If I am storing files in a per tracker subfolder system, eg: /downloads/seed/BHD and I’m trying to cross seed to NBL in /downloads/seed/NBL right now both torrents will appear, seeding, in the BHD category and folder location. I’m then left with the use case 1 dilemma of missing data due to automatic management.

Use Case 3 Torrents are matched in daemon mode immediately upon completion. For users who have 1 category for Sonarr downloads (or similar) and a subsequent category for imported Sonarr downloads, if the cross-seeded torrents are injected into the first category, they may cause additional looping imports. Eg: A season of a show could be imported after cross-seed injection, thus it is imported, overwritten and imported by cross-seed 1, then imported and overwritten again by cross-seed 2.

In either case, a manual action must be taken to move one of the torrent’s categories, hardlink the content of the torrent, then re-scan the data in the secondary category. It would be ideal to be able to pass through a custom qBittorrent category (or even better, a category per Prowlarr tracker optionally) that would auto hardlink the data instead of leaving it in place with the original data.

This would be an optional flag as not all users require hardlinks.

What are your thoughts on this? Thanks very much!

[mmgoodnow]

Thanks for the very detailed write up!

Hard links, symlinks, and partial data are an area of complexity that, when I wrote cross-seed initially, I struck a hard line stance against. That said, cross-seed has become a bit popular, and I will consider anything if enough people want it.

This feature proposal involves not only complexity in matching, but also complexity of configuration, which is made even more complicated by the fact that it would only work with qBittorrent. Please propose what the configuration would look like, both in the config.js format, and in CLI format (the hard one).

[SweetMNM]

Hi there! I will give my small suggestion on the matter… All of this “criterias” and deciding save paths based on tracker or based on season pack or not sounds way beyond the scope of the cross-seed project, mainly because there are other projects that already do it very well, and are already being used widely by people to manage and sort their torrents into categories.

Take a look at tqm for example. It allows you to filter based on many different properties, all in a clear and very nice config format. The only problem is that if tqm detects a torrent’s files are being shared with another torrent (cross seeding) it ignores them and doesn’t relabel them… Relabeling refers to recategorizing, and thus getting qbit to move the files.

Here is a scenario: I have a tqm rule to put all torrents from the tracker T1 into a t1-permaseed category after 2 days. Same follows for T2 and t2-permaseed because I like everything neatly organized. Now a movie was grabbed from T1, and cross-seed crossseeded it from T2 as well. At this point they are both in the radarr category or uncategorized perhaps, doesn’t really matter. What does matter is that tqm will now ignore them, and they will stay uncategorized or in radarr category for ever. Not only is it bad for organization, but more importantly it’s bad for situations where you change categories that have save paths across different drives (like having a torrent added to a SSD initially for speed and then moved to an HDD for long term seeding).

I have looked at patching the issue from tqm side of things but came to the conclusion there is not a viable way to do so. There is no way to hardlink from tqm and then tell qbit to change a torrent’s location, since that causes qbit to move the file, and it will be missing from the previous location for other torrents. Only sort of viable solution is to have tqm:

1. hardlink to a new path
2. remove the torrent from qbit without deleting files
3. add it again in the new path

but that will discard all of the stats that torrent had, which is not ideal. That why a solution needs to be implemented in cross-seed, when adding the torrents initially.

The solution I had in mind, that prevents cross-seed from having to implement from scratch what tqm does, and keep cross-seed as simple as possible is to provide a single --hard-links flag or config option, that when enabled does as follows (this solution and entire discussion is only viable when using qbit injection):

When ever a cross-seed is found, instead of adding it in the same path and to the same category, add it to a specific cross-seed category with autoTMM off. Specify the location for the cross-seeded torrent when adding to qbit to a specific configured cross-seed folder, with an increasing number added to it somehow (could be numbered subfolders inside the main cross-seed save folder). The increasing numbers will allow to cross-seed from more than one tracker, and still have the torrent files associated with each tracker hardlinked to a different path. At this point, since every cross-seeded torrent is hardlinked from it’s own path, organization to neat folders based on whatever criterias you wish can be picked up by tqm, or any other tool that allows categorization based on conditions.

Sorry if this write up turned into a long incoherent mess. I tried my best to keep it organized and convey my suggestion as simply as possible, hopefully it wasn’t too bad to bear through.

If this solution sounds nice to you, I also don’t mind taking a shot at implementing it.