[Feature Request] Allow mapping between dataDirs and dataCategory

[AN1MATEK]

Hello there,

To have my files organized, I prefer to have torrents in their respective folder (Movies/TV/etc) and not a dedicated folder/category just for cross-seed data.

My current solution is running 2 instances of cross-seed, one for Movies and one for TV, which I bet has some bad ramifications that I am not aware of. I then use qbit_manage to move the torrents to the *-Imported category of its kind. My config as an example:

    dataDirs: ["/media/torrents/movies", "media/library/movies"],
    dataCategory: "xSeed.Movies",
    linkDir: "/media/torrents/movies",

My idea for a fix would be to map a new dataDirs to new dataCategory and linkDir. Basically cross-seed will see where the file is at, and then choose the respective category. It could look like this:

    dataDirs: ["/media/torrents/movies",  "media/library/movies"],
    dataCategory: "xSeed.Movies",
    linkDir: "/media/torrents/movies",

    dataDirs2: ["/media/torrents/tv",  "media/library/tv"],
    dataCategory2: "xSeed.TV",
    linkDir2: "/media/torrents/tv",

This wouldn't break existing configs and also allow more granular control over where torrents are being planted.

I hope the idea could find an easy way into the code. From my perspective, it seems easy to implement.

[zakkarry]

qBittorrent now only supports injection into one category in v6 with linking. Unless you have an adaptation of the initial request that lines up with this, seeing as everything is linked, I am tempted to close this issue.

[AN1MATEK]

Wouldn't using legacyLinking keep this as it is? I am reading through the documentation but I cannot fully understand what the issue will be. I am in v6 with legacyLinking enabled and I am not having problems as you point out in the docs.

[zakkarry]

Then it is likely the combination of AutoTMM and particularly qbm are not something that affects you. Be that as it may, features are not specifically designed on a per setup/config basis - as that would require so much granular configurations that we would never stop adding settings to config.js

We're getting close to a point of potentially releasing a second pre-release which changes things to a setup which works across all configurations we are aware of (and intend to support) with qbit...but as i said - given that everything is linked, mapping specific data categories doesn't really make sense if everything is linked and everything goes to one category anyway.