你试试webgui的这个api，里面包含任务id infohash 等等信息，并且是通过xml格式返回的
/panel/task_list_xml
downloads.xml里面对应InfoHashHex字段
直接抄这一份代码吧，有现成的web管理
我研究一下，可惜我不会Java 
, 最后还是通过读取你说那个task_list_xml文件解决了，谢啦
有好东西可以分享出来哈~
target = 'http://192.168.xxx.xxx:xxx/panel/task_list_xml'
req = requests.get(url=target, headers=bitCometheader, timeout=30)
req.encoding = 'utf-8'
if req.status_code == 200:
root = ET.fromstring(req.text)
for tasks in root.iter('task'):
for task in tasks:
if task.tag == 'id':
fileID = task.text
我也是野路子出身 
1.96版本做了BT任务下载优化，解决了一个下载时候反复异常错误的触发自动限速导致网卡断流问题引起下载速度忽高忽低，1.96如果磁盘负载比较高时在内存用尽直到剩余500MB的时候会自动限速。
你要解决可以不用管，因为软件会自动进行限速
手动解决可以限制下下载速度，或者更换垂直的机械硬盘，叠瓦盘写入会很慢
也可以下载到固态后在移动到机械盘存储
停止过程显示黄灯代表正在把内存缓存数据写入到磁盘。
内存用满触发自动限速导致界面卡顿的BUG本贴已经反馈过了，等待后续版本更新。
当时查看内存、cpu、硬盘、网络都还有大量空闲
现在换到1.93倒是没问题了
能加入qBittorrent搜索引擎插件功能嗎?
对了，rss 评论框 截图框那能不能恢复以前那样走系统代理，现在版本一定要设置自定义代理选项
就是不设置自定义的情况下，让其走系统代理
如果设置自定义代理在走自定义
还有之前说的seen过程能不能间隔缩短点，我觉得2秒就可以了。。
还有就是界面上显示离线。。。没启用云服务的时候能不能去掉 很多人吐槽过了
你把长效关了试试几天，如果症状消失，那我觉得就是长效问题，我觉得现在普遍反映的任务一多关了bc任务不再自启动和下载慢慢减速，可能是因为内存现在都是8-16g然后下载多了长效就多，内存少长效又频繁的读盘导致盘一直零碎的读拖慢整体了
1.96新版本优化了长效上传缓存，现在已经不会频繁读盘了！可以观察新版的长效缓存命中率已经是99.9%了
区块填充文件能不能整合到一个文件里，每个文件要浪费106字节的额外空间，10000个文件就浪费接近1MB大小。
优化方法，只对第一个文件产生这段话，后续的9999个填充文件名均为_0表示，优化到2个字符
包括100KB的图片文件，如果填充32MB区块，需要浪费31.9MB的空白数据，能否实现用更小的方式去填充，例如对此文件标记为128KB区块，填充空白数据只需要28KB
而且应该还可以进阶一下，把填充文件变成1个，这样能省去大量的重复填充文件名导致torrent变大。种子内1000个所有图片文件，填充数据全放在同一个文件中。
填充文件记得是一个固定的机制，改了别家客户端就识别不出来了
我倒是建议把【____padding_file_0_如果您看到此文件,请升级到BitComet(比特彗星)0.85或以上版本】这句话去掉，实在是反向宣传，看着就像是“论坛文宣”一样的垃圾文件。
好像是这样的，，，我的想法没考虑到其他客户端的兼容性，不过缩短填充文件名这个肯定可行的，虽然一个文件这段话看着不多，，，但是10000个文件的时候，直接浪费1MB空间，改动后可以大量降低torrent文件的大小。
| 版本： | BitComet(64-bit) 1.96 Stable Release |
|---|---|
| 运行时间： | 18:27:41 |
| BitComet运行状态： | 总任务数:12606 / 正在运行:106 |
| 长效上传： | 105,665 文件可供做种 |
| 元数据下载： | 无 |
| 元数据缓存文件： | 6 |
| 远程下载： | 已禁用 |
| TCP连接数： | 已连接: 176 [最大: 无限制] / 正在发起: 186 [最大:200] / 等待发起: 11 |
| 本地IP： | 192.168.10.2 |
| 对外 IP： | 124.226.154.64 |
| TCP监听端口： | 22223 (防火墙/路由器已开通) |
| UDP监听端口： | 22223 (防火墙/路由器已开通) |
| LSD 的监听端口： | 6771 |
| 远程下载监听端口： | 无 |
| Windows防火墙： | 失败 |
| UPnP NAT端口映射： | 已添加 |
| 全局下载速度： | 550 KB/s [最大:无限制] 每任务最大连接数: 自动 |
| 全局上传速度： | 6.3 MB/s [最大:6.3 MB/s] 全部BT上传连接数: 20 |
| DHT网络节点： | IPv4: 4223 IPv6: 1160 |
| DNS 查询： | 已缓存： 588 等待中： 0 |
| CPU 占用率： | 2.3% (6核12线程) |
| 内存使用： | 工作集: 6.19 GB, 提交大小: 6.31 GB |
| 可用内存： | 物理内存: 6.42 GB/15.9 GB (最少保证: 1024 MB), 虚拟内存: 5.37 GB/16.9 GB, 进程空间: 127.9 TB/127.9 TB |
| 存储使用情况： | 本地存储： 51.2 TB / 54.7 TB (6.4% 可用) |
| 磁盘缓存大小： | 总大小：5.04 GB |
| 磁盘读操作统计： | 请求次数：33352663 (频率：490.4次每秒)，实际磁盘读次数：266650 (频率：2.9次每秒)，读命中率：99.2% |
| BitTorrent: | 请求次数：29901409 (频率：443.8次每秒)，实际磁盘读次数：129276 (频率：1.7次每秒)，读命中率：99.5% |
| 长效做种： | 请求次数：3451254 (频率：46.5次每秒)，实际磁盘读次数：137374 (频率：1.2次每秒)，读命中率：96.0% |
| 磁盘写操作统计： | 请求次数：6378286 (频率：20.9次每秒)，实际磁盘写次数：13428 (频率：0.1次每秒)，写命中率：99.7% |
| BitTorrent: | 请求次数：6378286 (频率：20.9次每秒)，实际磁盘写次数：13428 (频率：0.1次每秒)，写命中率：99.7% |
| HTTP/FTP: | 请求次数：0 (频率：0.0次每秒)，实际磁盘写次数：0 (频率：0.0次每秒)，写命中率：0.0% |
| 磁盘提速服务程序： | 运行中 |
| 累计下载数据： | 4.68 TB (本次运行: 109.3 GB) |
| 累计上传数据： | 25.2 TB (本次运行: 409.0 GB) |
| UDP 传输： | recv[274.9 MB]: 0 KB/s, send[1.02 GB] 17 KB/s |
| DNS 故障： | 126 |
命中96，不算吧
可以了，如果用1.96以前的版本，缓存命中率不会超过10%
可以百度搜索wps ScrLock，这是一个表格处理，键盘锁上的第三个灯亮起，ScrLock按键关掉即可
暂停刷新后可以更详细的防止来回乱跳以便观察用户列表，和进行封禁ip等操作。
如果下载完成后，触发移动操作会导致长效上传不进行工作
