2.11测试版

wxhere15 · 2024年10月19日07:51

欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~

v2.11 正式版预览
核心改进：文件读写模块支持访问Android系统中的contentUri路径
核心修复：远程访问开启HTTPS模式后，安卓版APP无法连接到桌面版

https://download.bitcomet.com/archive/BitComet_2.11_setup.exe
https://download.bitcomet.com/archive/BitComet_2.11.zip

macOS版：

https://download.bitcomet.com/mac/BitComet_2.11.0.dmg

Linux版传送门：点击链接

安卓版传送门：点击链接

v2.11 Beta4 [20241031]
界面改进：高级选项 network.ignore_remote_access_in_speed_limit 改为默认开启
核心修复：高级选项 network.ignore_remote_access_in_speed_limit 未解除全局下载限速的限制
核心修复：修改Web UI访问密码后，已登录的客户端应重新登录
核心修复：TCP监听端口被占用时未显示错误提示
核心修复：导入的IP列表文件为空时，IP过滤器没有加载手动指定的IP列表

v2.11 Beta3 [20241022]
界面改进：选项窗口IP Filter手动IP列表设置时自动去除无效地址，支持行首#注释
WebUI：peer list 可选择要显示的分组
WebUI：peer list 支持在所有任务解封指定peer
WebUI：peer list 修复 shift 键多选操作的问题
WebUI：修复选项窗口IP过滤器文件无法导入的问题

v2.11 Beta2 [20241021]
界面改进：选项窗口代理设置页面，增加通过代理服务器查询长效种子选项
WebUI：改进peer列表IP过滤器API接口
WebUI：修复peer列表IP过滤器无法封禁选中IP的问题

v2.11 Beta1 [20241019]
界面改进：选项窗口IP过滤页面，增加独立的手动指定IP列表
界面改进：BT任务peer列表右键菜单增加命令：永久封禁IP并加入手动指定IP列表、解封本任务全部peer、解封全部任务全部peer
WebUI：选项窗口IP过滤页面，手动添加IP功能变更为独立的手动指定IP列表
WebUI：peer列表右键菜单增加IP过滤器及显示数量选项
WebUI：查看菜单增加刷新间隔选项
WebUI：增加网络错误提示及重连按钮
核心修复：未分块对齐的BT任务，切换文件优先级时，文件首尾分块数据有可能未被正确写入磁盘

2908803755 · 2024年10月19日09:35

解封单个 Peer 真的能用吗，我测试了一下点击没有发送任何网络请求。

其它的解封全部任务全部Peers的倒是可以用。

hz6615997184904 · 2024年10月19日09:55

向长效种子服务器提交信息时，能否绕过代理？

查看截图，或更新 IP 过滤器地址列表等，可能需要启用 “将代理用于其他网络流量”
但这会向长效种子服务器提交代理后的 IP 地址，而一般代理服务器不会配置可用的端口转发，导致无法提供长效上传

我对 BT 任务配置分享率达到 500% 自动停止做种
但在开启代理期间，由于没有长效上传，仍然无法达到期望的上传量

zhuxiaoying85309 · 2024年10月19日10:21

在代理服务器上做端口转发或者frp就行绕过客户端代理设置肯定不合理长效本质上是tracker 可以放在tracker分类里面或者再单独新出一个选项

hz6615997184904 · 2024年10月19日10:41

对于分流目的的代理使用，确实可以配置端口转发

但通常使用代理是为了解决访问困难的情况，用户很可能没有代理服务器的管理权限
并且用户也不会希望经过远程代理服务器来中继流量，转发方案通常仅限本地网络代理的场景

目前发现很多用户在本地网络上开通了端口，但由于截图服务器访问困难而配置了代理
越是重度的 BitComet 用户，越习惯使用截图与长效上传，这个问题导致流失了大量的长效上传带宽

ie12 · 2024年10月19日10:46

@wxhere15 2.10官网上似乎没有更新？

zhuxiaoying85309 · 2024年10月19日10:59

所以新加个选项，使用代理查询长效种子就好啦

183631809 · 2024年10月19日20:16

大佬，安卓版本差不多一年没有更新了！

2908803755 · 2024年10月20日11:44

反馈一下， {"unban_range":"unban_all_task","ip_list":[]} 这个请求，解封所有任务的 IP 地址，请求为何必须要传递一个 task_id? 既然指定了 all task 的话，我觉得这个 task_id 传递的似乎毫无意义。

但是如果没有传递，则会返回一个错误：

{"error_message":"invalid task_id","version":"2.11"}

此外能不能提供一个接口，可以解封所有任务的指定 IP 地址的封禁呢？例如：

{"unban_range":"unban_all_task","ip_list":["1.2.3.4", "fe80::/32"]}

wxhere15 · 2024年10月21日02:31

感谢反馈，界面代码bug，下一版修复

感谢反馈，下一版增加单独的选项来控制

最近会更新

近期会更新

感谢建议，task_id是给解封指定任务内指定IP用的，解封全部任务IP确实用不上。下一版去掉无关的参数检测

ie12 · 2024年10月21日10:55

手动封禁的效果不错不过目前似乎没有对输入的ip进行格式检查
任意的内容都可以被输入

可以考虑像qb那样在手动添加使用列表的的形式
只有ip格式符合要求才能被添加

其中的封禁 IP 5分钟和封禁IP 1 小时似乎和以前的拒绝连接类似
是临时屏蔽但是针对的是IP不再是peer了？

wxhere15 · 2024年10月21日11:21

感谢反馈，下一版改进

永久封禁会加到全局选项的手动IP列表里，其他都是临时封禁（之前版本也是临时封禁IP，不是按peer封禁）

wxhere15 · 2024年10月21日11:21

beta2已发布，欢迎试用

2908803755 · 2024年10月21日16:42

IP 导入功能坏了

2908803755 · 2024年10月21日16:57

获取 Peers 的 API 可以设置只要某一种 Group 的 Peers 吗（例如只要 connected_peers）。

BitComet 的 API 发回来了一个超级巨大的 JSON 响应，给程序干 out of heap memory 崩溃了（并发查询 peers + 巨大 JSON 响应 = 耗尽堆内存），又因为工具特性，我必须请求完整的列表，而不是只请求前 N 个。

12MB 的响应有点夸张了

2908803755 · 2024年10月21日17:27

能不能加个接口，只解封所有任务中指定的 IP，现在直接全解封影响有些大？

wxhere15 · 2024年10月22日10:02

感谢反馈，下一版修复

下一版增加接口参数

wxhere15 · 2024年10月22日15:33

Beta3 已发布，欢迎试用

2908803755 · 2024年10月22日17:37

WebAPI 的性能似乎有点太差了？

我在 54 个同时下载的任务的 BitComet 进行性能测试，发现请求 /api/task/summary/get 端点的时候，一旦使用并发请求，哪怕是 2 线程并发，都会导致 BitComet 的 WebAPI 完全停止响应。

并发请求一开始，WebAPI 就停止响应，并产生大量超时。我对收到请求响应的时间做了打点计时，场景是对 summary/get 的 2 线程并发。

Request torrents details start (parallel: 2)
1729618508444 Received a RESP
[01:35:12] [virtual-120/INFO]: [保存] 已成功保存 4699 条封禁数据到数据库
[01:35:17] [virtual-126/WARN]: Unable to fetch BitComet task details
com.github.mizosoft.methanol.HttpHeadersTimeoutException: couldn't receive headers on time
1729618523492 Received a RESP
1729618523504 Received a RESP
1729618523520 Received a RESP
1729618528335 Received a RESP
1729618531634 Received a RESP
1729618531637 Received a RESP
1729618540601 Received a RESP
[01:35:46] [virtual-136/WARN]: Unable to fetch BitComet task details
com.github.mizosoft.methanol.HttpHeadersTimeoutException: couldn't receive headers on time
1729618546658 Received a RESP
1729618546672 Received a RESP
1729618546687 Received a RESP
1729618546703 Received a RESP
1729618548789 Received a RESP
1729618550973 Received a RESP
1729618552836 Received a RESP
1729618554482 Received a RESP
[01:36:05] [virtual-145/WARN]: Unable to fetch BitComet task details
com.github.mizosoft.methanol.HttpHeadersTimeoutException: couldn't receive headers on time
[01:36:07] [pool-5-thread-1/INFO]: [警告] WatchDog Service BanWave Thread 未在指定时间 65000ms 内得到重置，最后状态 Collect peers，正在转储进程线程信息，请发送给 PeerBanHelper 开发者以协助修复此问题

性能相当炸裂，这个响应速度不能用 QPS 每秒请求数来形容，可能得用 SPQ 每请求秒数……
BitComet 在 65 秒的限时时间内，仅仅完成了 54 个请求中的 16 个 task/summary/get 的请求，2 个超时，36 个请求则完全没有机会执行就全局超时了。

值得一提的是，如果减少启动的任务数量，响应速度能有明显好转。但考虑到用户不可能只运行个位数的任务，糟糕的 WebAPI 性能直接导致一轮查询下来，就需要超过 10 秒钟（基于 2 活动任务做的测试，本测试中的 54 个任务完全无法完成测试）。
再算上单独请求一次 Peers 的请求，这就很接近 BanWave 的时间上限了。