[讨论] 自行解析RSS + rpc 分发给客户端下载

[RanKKI]

嗯.. 我可怜的小树莓派因为是 32 位系统，没法用 qbittorrent，（不知道是不是我姿势不对）

想了下，完全可以自己处理 rss 的解析，然后调用客户端的 api 去下载内容，从而达到支持不同下载器的需求（aria2, transmission, etc.）

但看之前的讨论，似乎不在 roadmap 中。

如果可以的话，我可以做这方面，

目前能想到的一些优化和问题

• qbittorrent 和 aria2 似乎都支持事件派发， 在下载完整后可以直接触发事件
• 重命名之后是否需要，或者说是否支持保种。因为名字和位置都被改了.... （如果不需要保种，那就不是问题）

[EstrellaXD]

我记得 qb 是支持 32 位系统的，详见 Linuxserver

之前考虑过做其他下载器的支持，但是现在主要功能都是基于 qb 的特性提供的，换到其他下载器需要重造太多轮子，然后基于讨论群的调查结果就没有继续做 aria2 tr 这些的功能。不过之前开了一部分头，在 core 和 downloader 里面，您如果有兴趣可以接着里面的内容继续开发。

关于 qb 的事件派发，我之前尝试了一下有很多bug，并不能顺利触发，尚不清楚 aria2 的情况。因此也舍弃了这方面的想法，转而自己造轮子。

总的来说，目前用户反馈需求额外下载器支持的比较少，用 docker-compose 部署也很方便。支持更多的下载器个人觉得从得失来看还需要商榷。

PS 然后由于我个人电脑的问题没办法打包 32 位 arm 的 AB 🤦‍♂️，自己水平也有限排查不出问题。

[ash0080]

昨天晚上抓的几集新片下完后消失了( 我确定, 在 qbit 任务里看过了), 没进目标文件夹, 回收站也没在, 我不太清楚现在的除重机制是怎样的, 感觉是没有, 因为每次更新qb 里的任务都会所有拉一遍. 我是下载,存储文件夹分离的, 因为用媒体 service, 如果不分离, downloading 状态的文件会让索引出问题. 所以像 sonarr 那样解析+数据管理是绕不过的吧. 感觉现在就是丢给 qb 去看文件是不是已经存在, 但其实这样不能保证文件是否被后续服务又重命名过了, 还是得在内部维护一个已下载的数据记录才行.

[EstrellaXD]

昨天晚上抓的几集新片下完后消失了( 我确定, 在 qbit 任务里看过了), 没进目标文件夹, 回收站也没在, 我不太清楚现在的除重机制是怎样的, 感觉是没有, 因为每次更新qb 里的任务都会所有拉一遍. 我是下载,存储文件夹分离的, 因为用媒体 service, 如果不分离, downloading 状态的文件会让索引出问题. 所以像 sonarr 那样解析+数据管理是绕不过的吧. 感觉现在就是丢给 qb 去看文件是不是已经存在, 但其实这样不能保证文件是否被后续服务又重命名过了, 还是得在内部维护一个已下载的数据记录才行.

是否有相关 Log 提供一下，AB 不会对下载中的文件重命名。我个人偏向于是你 qb 的问题
重拉只是重新添加了 rss 这个问题好修复但是对于长期使用的人后期可能会需要自己手动删除重新添加，qb 的 rss 有存储上限

转至 #55 继续跟进

[RanKKI]

关于 qb 的事件派发，我之前尝试了一下有很多bug，并不能顺利触发，尚不清楚 aria2 的情况。因此也舍弃了这方面的想法，转而自己造轮子。

消息通知是用了 ws， 稳定性确实不太好， 因此轮询还是比较好的选择，

总的来说，目前用户反馈需求额外下载器支持的比较少，用 docker-compose 部署也很方便。支持更多的下载器个人觉得从得失来看还需要商榷。

确实，一个 Docker 容器就能跑起来还是很舒服的。

---

于是，我新开了个项目 RanKKI/Bangumi，提高下自由度

[EstrellaXD]

关于 qb 的事件派发，我之前尝试了一下有很多bug，并不能顺利触发，尚不清楚 aria2 的情况。因此也舍弃了这方面的想法，转而自己造轮子。

消息通知是用了 ws， 稳定性确实不太好， 因此轮询还是比较好的选择，

总的来说，目前用户反馈需求额外下载器支持的比较少，用 docker-compose 部署也很方便。支持更多的下载器个人觉得从得失来看还需要商榷。

确实，一个 Docker 容器就能跑起来还是很舒服的。

于是，我新开了个项目 RanKKI/Bangumi，提高下自由度

好的，已经在 README 中定向了你的新项目，然后本 issue 也会被关闭