能否支持订阅源指定下载器

[xiaozhikang0916]

我目前自己部署了几个qb和aria2容器，用来分别下载不同类别的资源，如qb-1下载pt站的，qb-2下载mikan的动画资源。

请问现在是否支持这样的指定下载器功能？

[jwcesign]

目前不支持。

可以问下，为什么要分开，归一是否可行？如qb-1下载pt站的，qb-2下载mikan的动画资源。

[xiaozhikang0916]

一是资源分类习惯，希望不相关的内容不要混在一起显示；

二是这些不同类型的资源希望分别存储在不同的物理磁盘上，目前我的做法是为不同的容器挂载不同的硬盘

[jwcesign]

理解。

第二点，存储在不同磁盘，这个可以通过目录挂载实现。

Kubespider目前还满足不了你的需求，我后续看看；也非常欢迎来贡献，适配这个场景。

[xiaozhikang0916]

可以通过目录挂载实现

如果是qb挂载不同目录实现这个需求，可能需要在触发下载时指定任务标签，也就是说需要为订阅源增加自定义下载参数的功能

[jwcesign]

有时间可以来一起开发下

[xiaozhikang0916]

81 为qb下载器增加了相对静态的tag参数，后续我的计划是为订阅源增加tag参数，触发下载时传递给下载器解析，例如传给qb下载器时跟静态tag组合，作为触发下载的实际tag参数。

但实质上这种方式也不太能满足最开始我想要的分类形式，因为目前看来只有qb支持分类参数。

而且考虑一个较为复杂的形态：

• 我部署了两个qb实例，其中qb1专门下载tv资源，qb2专门下载电影资源；
• 我注册了两个mikan账号，其中mikan1专门订阅tv剧集，mikan2专门订阅剧场版片源
• 我平时会去豆瓣下电视剧和电影

为了满足这样的需求，我可能会想要这样的配置：

{
    "mikan_providers": [
        {
            "name": "mikan_tv",
            "rss": "xxx",
            "path": "/downloads/mikan/tv",
            "downloader": [
                "qb_tv"
            ],
            "tags": [
                "mikan",
                "tv"
            ]
        },
        {
            "name": "mikan_movie",
            "rss": "xxx",
            "path": "/downloads/mikan/movie",
            "downloader": [
                "qb_movie"
            ],
            "tags": [
                "mikan",
                "movie"
            ]
        }
    ],
    "douban_providers": [
        {
            "name": "douban_tv",
            "rss": "xxx",
            "path": "/downloads/douban/tv",
            "downloader": [
                "qb_tv"
            ],
            "tags": [
                "douban",
                "tv"
            ]
        }
    ]
}

{
    "qb_download_provider": [
        {
            "name": "qb_tv",
            "host": "xxx",
        },
        {
            "name": "qb_movie",
            "host": "xxx"
        }
    ]
}

这样会将各种配置变成更加自由的数组（或者字典）形式，才能实际支持上订阅源指定下载源的功能。

但这样的改动太大，需要继续讨论一下。

[jwcesign]

1.我建议如下两种配置共存：

{
    "qb_download_provider": [
        {
            "name": "qb_tv",
            "host": "xxx",
        },
        {
            "name": "qb_movie",
            "host": "xxx"
        }
    ]
}
or
{
    "qb_download_provider": {
            "name": "qb_tv",
            "host": "xxx",
    }
}

2.可以给download provider加个接口，如是否和source provider的tag匹配，匹配就调用下载。

3.对于 但实质上这种方式也不太能满足最开始我想要的分类形式，因为目前看来只有qb支持分类参数。 其他下载软件就直接拒绝把，返回error就行

@miRemid 你怎么看？

[ultraji]

{
    "custom_download_provider_name1": {
        "type": "qbittorrent",
        "options": {
            "enable": false,
            "download_base_path": "/downloads/",
            "http_endpoint_host": "http://127.0.0.1",
            ...
        }
    },
    "custom_download_provider_name2": {
        "type": "qbittorrent",
        "options": {
            ...
        }
    },
    "custom_download_provider_name3": {
        "type": "aria2",
        "options": {
            "enable": true,
            "download_base_path": "/downloads/",
            ...
        }
    }
    "custom_download_provider_name4": {
        "type": "aria2",
        "options": {
            ...
        }
    }
}

这样会不会更好？

[xiaozhikang0916]

使用上面这种配置方式确实能更方便地让订阅源指定下载器。

然后我又好奇，我感觉这个项目之前的使用思路是配置多种全局下载器，一个失败了换另一个，想知道是基于什么场景定的这种下载策略；因为我还是觉得为不同内容配置不同下载器的操作比较自然，但这个操作跟现在的表现其实是有冲突的。

[jwcesign]

有些资源能被多种下载器下载，有些只能被特定下载器下载。 配置多种全局下载器，一个失败了换另一个，想知道是基于什么场景定的这种下载策略 - 对于能被多个下载器下载的资源，在某个错误时，需要尝试另外的下载器。

因为我还是觉得为不同内容配置不同下载器的操作比较自然，但这个操作跟现在的表现其实是有冲突的。- 这个感觉不冲突，有些指定特定下载器也可以理解。

[miRemid]

针对配置多种全局下载器，一个失败了换另一个，我一开始也有相同的想法，但是使用到后面发现其实下载失败的主要原因还是网络问题而不是下载器问题（BT可能会有Tracker因素，我的aria2下bt就没成功过所以添加了qbit）

但是在当前版本的多下载器配置上也存在问题，多个下载器并不能得到充分的利用🤔

多个指定源配置不同下载器则可以解决上面的问题

对于配置文件的修改，我赞同@ultraji提供的方案❤

[xiaozhikang0916]

一般来说，会给mikan配置qb+aria2作为兜底，给youtube、bili配置youget+aria2等等，针对源单独指定下载器和各自优先级会更符合使用场景。

[jwcesign]

1.我还是倾向于提供在一定程度上 拆分 源 和 下载软件 的做法，这样用户体验好一点，不用两边都需要关注（下载策略就逐个尝试已有的下载软件，直至成功，在source_provider.config中，tag/downloader默认为空）；

2.对于需要高级定制的下载策略，那就按 @xiaozhikang0916 @ultraji 描述的策略配置；

1和2是不冲突的，2的方案可以做到兼容1（如mikan_providers数组默认元素为1个，tag/downloader默认为空等）

@ultraji @xiaozhikang0916 @miRemid 你们觉得怎样？

[miRemid]

我更倾向于配置合并的方式，然后提供进阶策略配置教程供需要的人使用，默认只使用原始的简单策略

另外在当前提供的默认source_provider.cfg中

"bilibili_source_provider": {
    "enable": true
}

目前有必要对B站这类非订阅类型的资源进行开关控制吗，我感觉直接默认支持B站就可以了吧🤔

[jwcesign]

我更倾向于配置合并的方式，然后提供进阶策略配置教程供需要的人使用，默认只使用原始的简单策略

配置合并指什么意思，可以给个例子吗？

目前有必要对B站这类非订阅类型的资源进行开关控制吗，我感觉直接默认支持B站就可以了吧

+1

[jwcesign]

cc @miRemid

[miRemid]

我的想法就是上面提到的2兼容1的那种形式，一开始把提供在一定程度上 拆分 源 和 下载软件 的做法想复杂了

[xiaozhikang0916]

普通配置，不指定下载器，按默认规则尝试全部可用的下载器：

{
  "mikan_tv": {
    "type": "mikan_provider",
    "rss": "xxx"
  }
}

特殊配置，按自己指定的下载器和顺序进行尝试：

{
  "mikan_movie": {
    "type": "mikan_provider",
    "rss": "xxx2",
    "downloader": [
      "qb1", "aria2_1"
    ]
  }
}

这种形式是否可行？

PS：纯个人喜好观点，有没有可能支持yaml格式的配置

[jwcesign]

这种形式是否可行？

这种是挺好的，但是现在有个担心，如：https://github.com/jwcesign/kubespider/blob/b4b3484482663b8742c14c904df648dda77d240b/kubespider/source_provider/bilibili_source_provider/provider.py#L37

收到一个url，会遍历所有source provider，找到对应provider解析资源地址，如果存在多个，那选谁？

1. 直接选第一个，然后break？
2. other?

纯个人喜好观点，有没有可能支持yaml格式的配置

我觉得是可以的，yaml可能还简单点，可以搞下（如果你有时间）

[xiaozhikang0916]

如果存在多个

作为用户主动配置的多个订阅源，同时响应会更合适；这一般会输出两个结果：

• 如果多个订阅源指定了不同的下载器，那就都发起下载，可能是用户的一个冗余备份操作；
• 他们用了同样的下载器，在下载器那边通过重复报错进行拦截。

这在主动配置的时候应该是有预期的

[jwcesign]

可以，那按这个策略来 我assign给你 @xiaozhikang0916