both_finished 状态判定是连接peer成功，并且对方回显自己是种子，此时就会加入both_finished里
可以百分百确定对方还没跑
对资源发布者有用，花钱组服务器提高用户下载速度
HTTP？
所以就是他是計算你現在用戶的健康度丫…
把種子加上就沒意思了…本身種子是連不上…連上就斷掉…而且數分鐘內都不會再重連.
現在只計算下載中的挺好…
最近亂點界面…有時候還真因為刷新閃爍後…下面的表事件(EVENT)失敗…導致空白一片…估計是沒得到鼠標點擊的任務…或有延遲攻擊(把表刷新成空白)
另外建議一下新增一個設定允許用戶默認地縮小DISCONNECTED(或所有)用戶列表…
那些有20000用戶以上的卡頓尤其明顯…對我樓上說的表刷新時間更嚴重一些
可以发布一个Linux版的比特彗星吗？
目前比特彗星电脑版仅支持WIN/Mac端，但也有不少用户使用Linux系统，这些Linux用户无法使用比特彗星，并且现在随着国内大陆开始大力发展并推广国产Linux系统（麒麟软件：openkylin(根社区)/优麒麟(发行版)/银河麒麟(商业版)）和（统信：deepin v23(根社区)/deepin v20(发行版)/uos(商业版)）。
我相信Linux用户也会越来越多的，政企/高校目前是推广的主要阵地，我相信比特彗星的用户群体里也不乏包括高校学生群体，希望早日可以在Linux系统中用上比特彗星！
感谢建议，下一版改进，移动前显示确认对话框，增加一个选项
感谢建议，后续版本改进
感谢建议，后续版本改进
感谢建议，后续版本改进
感谢建议，后续版本改进
可能是升级界面库之后出现的问题，回头研究一下
具体是哪个界面？麻烦截个图看看
请问安卓版本？高版本用C++代码读写APP私有数据目录之外的文件很困难，目前还没好的方案
感谢建议，已在移植中，后续会出测试版
方便做种者观察种子健康度，我觉得还是有意义的，不然只有下载过程才能看到健康度。
安卓13，U盘的话网上查了下好像有专门的api，其它app能正常读写U盘文件，比特彗星不可以，直接看不到U盘存在
最理想是的这种命令管理，支持centos6.10 x64系统直接运行，同时输出webgui，配置文件放在同级目录的etc文件夹，或者和Windows一样放在同级根目录即可
/home/bitcomet -v
/home/bitcomet -h
直接运行 /home/bitcomet 会启用2个进程，一个为守护进程，检测主进程是否在工作运行，例如意外退出后，通过守护进程检测到会自动重启主进程
smb的问题也麻烦看一下啦，utorrent是没有问题的，使用nas做smb远程访问的人挺多的，处理问题的优先级应该比较高
有时候会遇到某个peer没有速度是什么问题呢？psping查看对方tcp端口都是通的，抓包也看到正常回复ack请求
可以看到持续5分钟连接时间，速度一直是0，不会有任何速度，但是一旦暂停任务，重新开始任务，这个速度为0的peer马上就能正常工作起来，所以感觉问题发生在比特彗星下载方
就是下方視窗…任務狀態 檔案列表 用戶 全局統計那些…因為你不同狀態下有不同的頁面數量…如果可以設定成恆定不變就好了…
當沒有使用服務加速下…程序使用硬盤100%寫入中時…種子市場會卡住0.0%載入…估計是佔用相沖了吧?
另外…能不能增加識別 種子特徵碼拖拉識別(如特定長度和沒有網址特有的斜線或點號或網域?)?
之前也上報過…目前還是一樣會變成HTTP下載識別…
那如果種子都不在呢? 只有一個種…但是他跑了…你還要5分鐘才會刷新下一次連線…那你走了…不就死種了?
如果是熱門種…根本不需要看這個健康度…
未能正确识别种子的对齐状况？
用qBit v4.5.4 x64 qt6 制了个种（v1格式的，此版本仅能制作此格式），开启了 “优化对齐”，将生成的种子放在Torrent file editor里面查看可见生成的 .pad\0 填充文件，但放入彗星里下载，摘要里的状态就是 “未分块对齐”。
不知道是不是彗星的问题？
比特彗星是基于bit协议bep47标准开发，qb没有根据bt协议规范去开发功能，是github上 @Chocobo1 这一位开发者自己写的功能，所以导致了兼容性问题
协议规范地址：bep_0047.rst_post
而且从你的截图上可以看到，4个文件都处于区块1中，由此可以表明，并没有进行区块对齐，区块对齐后文件不会产生相邻的区块内容。你可以用比特彗星制作一个种子，勾选分块对齐来截图对比区块情况。
建议联系qb开发者解决，让其遵守bt协议规范，也可以让比特彗星做一下兼容支持qb的区块对齐。
很遗憾，Pieces 指的是分块数量，不然 Pieces 2018 作何解释，从块2跳到块2018？
又创建了一个未勾选优化对齐的，分块大小1MiB，其中一个60KiB的文件被分成了两块。
对比而言，qb的分块对齐应该还是在工作的。
更技术性的东西我不了解，但感觉问题好像是出现在了不同的实现方式上是怎么回事
Padding files are synthetic files inserted into the file list to let the following file start at a piece boundary. That means their length should fill up the remainder of the piece length of the file that is supposed to be padded. For the calculation of piece hashes the content of padding file is all zeros.
http://bittorrent.org/beps/bep_0047.html
edit: 又制了一个多文件种子，开启优化对齐，分块大小设到4MiB, 大过每个单独文件的大小，看看块剩余会不会拼接。
可谓一BEP47各表，不知道我说的对不对。
有没有qb制作的磁力，我试一下
比特彗星是基于bep47 bt协议标准开发的区块对齐，如图所示，不会产生相邻的文件区块，也不会显示pad的区块文件，torrent文件打开可以看见有-p属性隐藏，客户端实现自动填充pad，无需通过网络下载pad文件
