固态还是机械？
机械… 之前任務中斷重啟都會算… 現在很少看到黃燈在算進度…
3W队列刚好=128M内存开销，看来经过了精密计算
| 2020-10-19 03:53:39 | Failed to announce: DHT network is disabled in global options. |
|---|---|
| 2020-10-19 03:53:41 | Failed to announce: DHT network is disabled in global options. |
任务上的tracker DHT日志显示应该改一下，提示队列已满，这样友好些。而不是全局选项关闭
最好能汉化下，全局关闭是这样的，所以上面那个提示应该分开为不同的队列已满提示
比如显示为 已禁用(队列已满)
手动把队列完全放空为0后，任务的DHT应该在如果1分钟内队列持续为0后再次尝试启动？我看了下他永远是显示DHT network is disabled in global options了，只有手动点击更新tracker，dht才会再次工作
而且手动尝试tracker更新的时候，队列值已经大量超过了限制值，是否没考虑到手动更新的情况进行限制丢弃。
1個讚
队列满不会影响dht tracker，只是无法接收新的查询请求。你看看是不是确实禁用DHT了？
没有禁用呢，你看我的图，如果全局禁用是显示
单个禁用是显示
你测试可以限制每秒UDP发起为极小的值，然后观察队列情况就知道了，一段时间后，DHT TRACKER就会显示上面的那样Failed to announce: DHT network is disabled in global options.
我测试了，已经达到上限并有丢弃的数据包了，但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无响应一阵子