2.11测试版

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

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任务,切换文件优先级时,文件首尾分块数据有可能未被正确写入磁盘

2個讚

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

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

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

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

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

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

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

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

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

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

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

1個讚

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

反馈一下, {"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"]}
1個讚

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

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

最近会更新

近期会更新

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

2個讚

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

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

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

感谢反馈,下一版改进

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

2個讚

beta2已发布,欢迎试用

2個讚

IP 导入功能坏了

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

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

12MB 的响应有点夸张了

1個讚

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

1個讚

感谢反馈,下一版修复

下一版增加接口参数

下一版增加接口参数

Beta3 已发布,欢迎试用

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 的时间上限了。