试试我之前发的办法，先全选，批量tracker修改，清空，然后在停止
或者BT任务列表，把排序去掉，，，在停止
我没试过是否可行，
但那对于每个新用户都得进行这个操作是否过于麻烦，
请官方重视一下~~~
v1.96 Beta3 [20221031]绿色版
4f980b23b9662767edd3b69946190ad015f7bb66
v1.96 Beta3 [20221031]
任务列表还是会很诡异的跳动
看了你的截图，network.max_connecting_connections_per_tracker 新设置项好像没有生效。默认值是6，每个tracker地址发起连接数不应大于6。我这边测试是正常的，不知道哪里出问题了
大概多少个任务？卡顿是指界面没反应，还是指任务长时间处于“正在停止”的状态？
默认值6试过了，一样没用，所以才改成了10000避免后续被限制引起阻塞导致更多的问题出现。
默认值6，没区别，也是卡好久好久十几分钟没反应
所以和这个无关，如果tracker加的多的话，同时任务数多，说不定还容易拥堵好几十万的等待发起
目前已知的就是，，，启动软件后，把BT任务列表排序关掉在启动全部的上千任务，基本可以瞬间进入上传状态了。
很诡异，刚刚把任务列表排序取消了，在试下好像又不能瞬间上传了，等了3分钟还没开始。实在不知道啥问题堵着了，最明显的特征就是占用1个CPU核心吃满
上面的消息队列看的出什么问题吗，，不是很懂，看了一眼正常上传的时候，消息队列是这样的
任务列表这个双击开始下载或者做种来回跳也很恶心–！
消息队列总长度超过10就会延误网络传输处理。每个任务启动后都会有一个界面刷新消息，做种任务有2个，所以上千个任务会堆积上千个消息。界面刷新再加上排序，就会处理很久。下一版对界面刷新做了优化，会有改善。
这是任务列表排序优化造成的，下一版修复。
为什么我下载很多版本比特，下载速度为0，只有迅雷可以下载
那么看来，，，之前反馈的BT任务硬盘磁盘活动变高的时候，下载速度突然变成0出现断流也是这个问题了？
Beta4里面任务启动、结束时的界面刷新优化过了，再试试看
已修复
不一定，下次遇到时可以看看统计里的消息队列
v1.96 Beta4 [20221104]绿色版
7a5921233935547d29721f4217dd56a57a6c62b8
测试了！效果巨好！现在启动上千个任务只要1-2秒就开始进入上传状态了。事实证明和network.max_connecting_connections_per_tracker 那些选项无关，，是界面刷新卡了导致不进行上传。
磁盘临时写入高负载的时候，网卡可看到下载速度变成0KB/s，消息队列是0，只有BT任务会这样，HTTP任务不会出现这种情况，HTTP优化的挺好，会继续下载到磁盘写操作缓冲区里。BT任务这个断流你看看怎么回事？
简单点的复现方式你可以用PrimoCache设置延迟写入，写入模式原始，每60秒一次把组合的块写入硬盘。所以会产生一个长达几秒临时的写入峰值。此时比特彗星下载BT任务的话，就会掉速成0，HTTP任务正常下载不会出现掉速。
好像有个小问题，，软件启动后是端口通的绿灯，启动全部任务后不知道偶尔为什么会导致端口TCP无响应，直到重启软件才恢复端口，大概50%几率会遇到这个问题。
尝试修改network.max_connections 限制或者无限制都会出现。然后只能本地发起TCP，收不到来自远程连入的peer
端口绿灯正常的情况下会响应curl: (52) Empty reply from server
curl 127.0.0.1:22223
出问题的时候响应
curl: (7) Failed to connect to 127.0.0.1 port 22223 after 2060 ms: Connection refused
ipv4和ipv6的本地端口访问都会这样。。。挺奇怪的
curl [::1]:22223
看起来应该是被比特彗星软件代码里什么东西限制了。。。出问题的时候我选项里面换一个其他端口，在换回去原来的就秒恢复，还是说这是Windows系统层的毛病？我看资源管理器里面进程监听到的端口还在，毕竟系统看到监听但是端口不通，，大概率是系统毛病？如果是系统的BUG那就没办法了！但是我重启了系统也会出现这种情况，以前版本好像没遇到过，，更新beta4后第一次遇到这种怪异现象
在解决下这个问题和上面的BT任务速度归0的问题。。和UTP上传速度慢导致下载速度也慢的问题，Transdroid看到代码合并了，不过还没发releases，都解决应该就能发正式新版本了。
可下版本去解决
UTP速度问题！！！
打洞的问题，bittorrent.utp_after_holepunch选项的强制可删了，，设置强制不起效果而且已经失去作用了，不如删了强制选项，保留自动检测TCP→UTP→打洞请求轮询效率好。
用户列表添加用户选择utp发起方式也是坏的了，，不管选哪个都是永远utp直接发起，感觉这个手动添加和选中peer设置发起方式选项也没用了可以删了。
我测试发现了，私有种子下打洞是等待建立连接过程请求自身客户端已经建立TCP和UTP传输连接的所有peer，这样测试了也没问题，，私有种子下测了成功打洞了。
之前还以为是发送UDP打洞去请求此peer对方客户端中获取他人已经连接UTP的peer列表udp远程端口信息返回给自身客户端。论第二人称视角和第三人称视角的差别。
beta5 已经改成HTTP任务一样的处理方式了，剩余内存不足时再限速，而不是直接暂停分块请求。可以试一试效果。
测试了一下，暂时没能重现
这两个选项本来是用于测试用的，普通用户用不上
话说制作种子默认自动检测的区块是不是太小了。
比特彗星生成出来是256KB，utorrent是1MB，libtorrent好像是2MB
软件生成种子太小的区块，虽然更加利于P2P上传分流，但是用户下载时候写盘次数会过多。