我测试了，已经达到上限并有丢弃的数据包了，但tracker状态暂未出现你截图的状况。估计你的情况是该任务在DHT禁用期间刷新了一次tracker，而开启DHT后该任务DHT tracker还没来得及再次刷新
感谢回复，我具体测了下，发现其实是另一个因素引起的，百分百复现问题，就是下图中的DHT延迟启动
感谢反馈，确实是DHT延迟启动引起的问题。如果任务在DHT启动前先一步启动，后续就不会再主动刷新DHT状态了。后续版本修复
谢谢小樱和 wxhere15等各位大佬让比特彗星越来越好，让用户用的放心，省心，安心
2個讚
1.72 beta4 已发布，欢迎试用
对于http任务能否加个校验功能？可以通过右键快捷进行校验，可以检查文件的MD5和SHA1值显示出来
例如任务路径旁边有个播放按钮，如果值不存在，也可以点击按钮进行校验，右键菜单中或者点击按钮两种方式
虽然有第三方软件，但是总没自带来的方便吧
請問一下… 觀念是否正確?
哈希進階設定…
bittorrent.hash.check.on_finished
如果設定 [是]: 任務完成後才算哈希, 下載過程中 cpu 使用率較低, 適合低階 cpu
如果設定 [假]: 任務進行中計算哈希, cpu 使用率較高, 適合高階 cpu
不管是否选择是或者否，任务进行中都会进行区块校验，如果选择是，那么任务下载完成的时候还会额外进行一次完整校验保证文件完整性，选择否，下载完成后直接进入做种状态
接着上面的帖子
停止所有任务，关闭DHT UDP发起，现在的版本最高长效上传速度只有17MB/S…
只跑一个核心，导致界面卡顿，求优化。。
单文件的种子大小预估出现了错误
长效种子，应该要独立出一个线程来跑防止界面卡顿？和制作种子一样，单独新建一个CPU线程去工作
而且有没有办法做多核心优化啊，，其他线程都很空闲，希望长效能突破17MB/S的上限！
取消那个17MB/S的任务的长效，此时界面瞬间流畅不会卡了，占用直接降低到了0.1%
BT网络传输的情况，，视乎比长效更省资源？当然问问有办法都做CPU多线程吗，，
1個讚
開啟長效種子會導致BitComet任務完成後，BitComet會沒回應30秒~1分鐘，
此時硬碟IO跟網路上傳下載也是完全停滯狀態，
要等到BitComet恢復後，下載才會重新連接，下載速度才會慢慢爬升，
關閉長效種子後就排除這個棘手問題，
不知道是否跟我長效種子太多的因素影響，
整個問題的查找歷程可參考以下討論：
每次有任务下载完成后Bitcomet无响应一阵子
我先前就反映過了，單掛BT時整體CPU使用率過高，
實際用功耗計測BC真的越改越耗電，原本單單掛BC整機耗電穩穩的在40~42w跳動，
近幾版單單掛BC整機耗電卻來到嚇人的63w~43w，一天24h要多耗掉將近500w，
一個月要多耗將近15度電，這可不是小問題…
1個讚
长效应该是有问题的，旧版本1.5x没啥问题
这么耗电啊
多耗了50%電力，40→60w很誇張，不然我不會上來反映，
官方一定要正視這個問題…
应该是和我测试版这贴之前说的，长效种子用的是CPU主线程，和界面跑到一起去了，然后就会变卡
BT传输也是主线程。。然后就卡了
电量消耗啊，，盲猜DHT引起的
