也许主程序和其他辅助程序的签名可以分开
至少和更新程序的签名分开 或者更新程序采用单独的签名
以防止证书再被吊销
文件名字是（1）（2）这种格式的文件，制作完种子会重新下载，有办法解决吗？
说得具体一点看看，我这边复现不了，制种完成后正常100%保种。
对文件重命名，通过只保留后戳，把文件名删了的方式让它自动排序，我是win11系统。然后做种就会这样
你看，做完种子，这里变成下载了，正常应该是变成黄色上传箭头才对。
然后文件夹变成这样了，做种的时候我是选的整个目录
magnet:?xt=urn:btih:GN36BR2NI4PVLUSBGOWFQPDMKGOBRSDQ
啊，复现成功了
原理大概摸清了，就是彗星在读取文件名或文件夹名称时，会忽略开头的空格，导致制作出来的种子里的文件名是不带开头的空格的，而实际的文件名却带空格，二者匹配不上，导致制种出来的任务进度不是100%。
至于为什么文件名前会有空格，就如楼上操作的那样，选中多个文件，批量进行“重命名”时，如果只保留后缀名，就会重命名为【空格(1).jpg】这种文件名。如下：
种子市场里，多选任务右键下载元数据这个过程是在主线程吗？也可以放进工作线程
我有一个困扰，使用bitcomet下载的时候，好久都无法连接到peer ，同一个磁力qbittorrent，fdm都开始下载了，bitcomet还是没有速度。 而且我发现bitcomet连接用户数量往往不足其他下载用户的数量。 是我设置的问题，还是其他问题。
软件的默认配置特别保守，需要自己优化一下下面的建议数值，然后看一下统计页面是否还有发起等待的阻塞现象
network.max_connecting_connections 10000
network.max_connecting_connections_per_tracker 10000
network.start_connect_interval_ms 0
network.tcp_connection_timeout 10
换个热门点的资源试试？可能是死种，或者没有正确添加tracker服务器找到用户所以导致peer数量很少
C4E6EC63A58923580CDC5D83136AE1740A48D600
测试都是比特彗星速度秒杀qbittorrent的
比特彗星版本为当前最新2.14
qbittorrent版本为当前最新5.1.0 lt2
其实还是远控看看找问题比较快，毕竟你可能没提供关键线索。
可以私聊发我QQ号，我加你QQ，远控看看你彗星具体哪里不对劲。
在这些tracker服务器下载的地址。bitcomet 总会有一定的前摇，其他bt软件贴完磁力，很快就会有很多用户，然后进行下载，bitcomet要等号一会才能出来。不管冷门种子还是热门种子都是一样。根据你的设置调整完，速度稍微快了一些些，但是对比还是会慢其他一些。
https://cf.trackerslist.com/best.txt
https://newtrackon.com/api/live
https://newtrackon.com/api/stable
https://trackerslist.com/best.txt
https://trackerslist.com/all.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_best_ip.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_ws.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_https.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_http.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all_udp.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_best.txt
https://cf.trackerslist.com/all.txt
https://raw.githubusercontent.com/ngosang/trackerslist/master/trackers_all.txt
https://cf.trackerslist.com/http.txt
https://cf.trackerslist.com/nohttp.txt
https://www.gbsat.org/bt/tracker.txt
https://jsd.cdn.zzko.cn/gh/XIU2/TrackersListCollection/http.txt
https://jsd.cdn.zzko.cn/gh/XIU2/TrackersListCollection/all.txt
https://jsd.cdn.zzko.cn/gh/XIU2/TrackersListCollection/best.txt
https://newtrackon.com/api/add
https://newtrackon.com/api/all
https://newtrackon.com/api/http
https://newtrackon.com/api/udp
https://raw.iqiq.io/XIU2/TrackersListCollection/master/all.txt
https://cdn.staticaly.com/gh/XIU2/TrackersListCollection/master/all.txt
https://fastly.jsdelivr.net/gh/XIU2/TrackersListCollection/all.txt
其实tracker加太多的话反而慢，因为边际效益太低，而性能消耗却是随着tracker数量线性增长，所以用这4个就行，就像我截图那样设置，要记得把自动更新tracker服务器列表关了不然一个更新又变成几百个tracker了。
udp://52.58.128.163:6969/announce
udp://tracker.opentrackr.org:1337/announce
http://tracker.renfei.net:8080/announce
udp://open.demonii.com:1337/announce
收到 谢谢大佬的帮助。
我描述下，你是不是遇到这个问题？
这个之前反馈过，是建立peer连接，openssl对peer进行aes加密传输时候，首次连接peer成功后会马上断开一次，peer跌落到disconnected要等待30秒后重连，二次建立连接之后缓存在内存中就好了，之后在怎么断开重连都是瞬间了
反馈过不过开发者好像还没修复这个问题，把协议加密从优先改成自动检测，此时发起的请求是未加密的，连接新的peer时就不会断开了，不过肯定是建议开着加密的，不然传输的数据都是明文
不知道什么时候会触发，，有点概率性不是必现，大概测试100次有5次左右出现，概率非常低，可能开发者测试的时候没有复现，总之显示图片这样就是复现成功
感觉可能是首次连接时，双方https证书交换失败引起的断开
好的，收到。
奇怪，我总记得以前peer连接DHEv2的时候是交换证书形式的openssl的aes加密方式，，，刚发现居然不是，还特别试了很久以前的历史版本也都是tcp-rc4加密，难道我在做梦？
总之出现peer握手出现加密首次连接瞬间断开的概率非常低，影响不大，，等30秒自动重连peer就好了
手动列表的默认规则似乎存在一些问题
其默认状态为允许 在启用后似乎会使得订阅列表中的规则被跳过
即订阅规则不起作用了
@wxhere15
冒昧的问一句，bitcomet 如何下载能超过20M 嘿嘿 如何设置
数据流向图，符合当前版本设计吧？手动＞订阅
用户连入
↓
IP过滤器（手动规则合并订阅规则）
↓
客户端列表
↓
客户端过滤器（手动规则）
↓
客户端过滤器（订阅规则）
↓
保持连接
是指超过20MB的种子文件吗？