元数据下载什么时候能和其它BT软件一样，多个peer同时累加进度，然后不会暂停下载重新开始后 元数据又变回0重新从头开始
cpu问题应该很好优化才对，，但是不知道官方为什么还没开始优化，应该来说捕获个dmp然后能分析cpu在哪行代码使用，然后改代码优化吧
之前提出后没有关注后续的更新，今天才发现1.80版本已经支持implied_port和PEX端口替换。
这边测试后，发现DHT的implied_port工作正常，并且能正确发起uTP打洞，让两个NAT3客户端建立连接。
但禁用DHT后，仅测试PEX时发现提供的仍然是本地监听端口，而不是外网端口。
该视频实际上也是通过DHT获得NAPT后的端口，而非PEX
视频位置03:30中可以看到，在未连上任何peer，也就是未进行PEX前，就已经获得了136.243.24.11的公网端口62643
该视频未列出用户来源，但根据界面可以推断出是DHT
是没有正确替换端口，或者是同一IP多个端口被去重了？
抓包看到的都是编码后的BT流，不好解读……
禁用DHT的情况，需要发起请求为UTP时候成功连接到对方，PEX才会响应自身NAT1打洞后的端口进行交互peer列表
也就是说只有AB两人的话，必须要有一方已经打洞成功能够访问到对方，你测试时候由于双方是NAT3，则需要借助第三者来进行ABC打洞，视频中演示的是NAT4类型（DHT也算一个第三者）
qbittorrent 至今还没实现NAT1打洞，开发者甚至不知道什么是NAT1，2024年了，比特彗星依旧是全球唯一支持打洞的BT下载软件
包括qbittorrent 对IPV6也不支持
测试时就是用3个客户端，其中一个公网（S），两个NAT3（A与B），并且强制uTP连接
预期的结果是，当公网S与内网A建立uTP连接后，会把内网peer实际连接的公网端口，而不是其通告的本地监听端口加入到PEX列表
然而，当内网B通过uTP连接上公网S后，进行PEX获取到的仍然是内网A的监听端口而不是公网端口
同样地，内网A在这之后从公网S获得的PEX，也是内网B的本地监听端口
同时测试了qBittorrent（基于libtorrent），虽然lt的源码中有PEX端口替换的部分，但实际上也没有交换到NAPT后的公网端口
在implied_port正常工作的情况下，PEX端口替换重要性不高
但既然已经做了，希望它能正确工作
你指的是比特彗星还是qb，比特彗星在1.81版本就开始完美NAT1打洞了，而且支持2台客户端打洞，PEX交互端口也是正常工作的，1.95版本优化了加快交互PEX，大概建立连接开始传输有速度后等待7秒左右执行打洞（一定要有速度，如果0KB是不会交互PEX打洞信息的）
NAT3理论上是不能打洞的，对比NAT1来说让NAT3打洞实现起来比较困难，毕竟NAT3无法保持外部UDP端口打开，NAT3的打洞成功率会低很多
qb那边和开发者联系过，，，然后他们都不懂NAT1，看issues历史消息就知道了
比特彗星PEX如图所示，比特彗星会正确使用NAT后的远程端口用于打洞
DHT如图所示，NAT3打洞后的端口，成功被公网ip服务器反向回连成功，NAT3打洞的前提一定是对方有公网ip或者NAT1，所以NAT3打洞的价值不大，最好设置好DMZ或者upnp来获取NAT1
然而在qb，无法进行任何方式的NAT1打洞
好久沒用…2.06看上去多了雙擊停止驗證任務…
剛剛任務跳動點錯了個1tb的任務…而且還不帶中斷記錄…
能不能增加一個確認提示呢…
233333
剛剛從QB回來的…QB沒了硬盤快取設定…實在太垃圾
下載幾個MB/S…硬盤被扯爆100%使用率…
立馬又刪掉了…
外國人的思想是很奇怪的…
@wxhere15
目前有优化utp的计划吗？
现阶段utp有比较严重的性能问题 以至于几乎不可用
为保证软件和系统的正常运行只能禁用 utp
这使得打洞功能也不可用
之前帖子就讨论过，，qb更倾向使用系统级的缓存，隐藏在系统中不可见，容易被其它程序刷新冲掉，进程不占用独享内存去使用导致取不到缓存，所以很垃圾
好像是
导入和导出下载列表
他人共享 (18,560,000).bc_bak
16 GB RAM 吃了 15 GB,
比特彗星 崩溃 造成的,
这几天 没再发生.
麻烦改一下.
删除任务时
按 Delete 有作用,
但
按 最右边的 数字区 的 Del 没有作用.
(指 所有下载(下载中/完成/未完成/正在运行)
HTTP/FTP 下载 取得 服务器 上的 原始日期时间
例:
https://download.bitcomet.com/achive/BitComet_2.06.zip
下载 文件 原始日期时间 应该是
2024/01/18 上午 12:43 32,432,861 BitComet_2.06.zip
另外:
如图:
請問開通 [好友上傳通道] 過一陣子就沒有上傳速度?
查看旗標狀態上傳並沒有通道窒息
全局6M上傳頻寬扣掉 1M 長效,也還有 5M 可供上傳…
當停止任務後重新啟動，上傳速度就會恢復正常，初步感覺並非對方的問題。然而，上傳一段時間後速度又會歸零，必須手動重新啟動任務才能再次享有正常上傳速度。不太清楚這可能是什麼問題，是否有可能解釋或解決這種情況呢？還是要滿足什條件才能實現優先上傳?
所以才問問能不能加上…關閉任務提示…畢竟如果數TB的種子…校檢一次要數小時…誤點心態要爆炸…
提个建议，关于任务列表的【分享率】列。
【分享率】的显示规则是：
【如果总下载量为0，分享率=总上传量/种子体积】
【如果总下载量不为0，分享率=总上传量/总下载量】
所以出现一种情况，有时候下载完成的任务，下载量远小于种子体积，导致分享率超高。
建议就是，希望可以加个高级设置，使所有任务都以【分享率=总上传量/种子体积】进行计算和显示，这样可以直观地知道【任务上传了多少份】。
@wxhere15
通过命令重载配置文件的功能也安排一下吧
有了这个功能就可以轻松实现通过其他程序来修改彗星的设置
各种自动化实现起来也会更加方便
感觉不太合适，可以直接做到累计上传量选项卡里面，气泡弹出显示比较合理，分享率讲的就是分享了多少的流量比例，产生了100M下载，那肯定要计算100M，包括PT站等流量统计全都是这样计算的，而不是所谓的种子体积，用种子体积的时候，如果只选择了BT任务中其中一个文件，此时又该怎么计算呢？所以在累计上传量里气泡弹出这样上传了多少种子体积比较合适？
