看不明白，能不能用简体解释下是什么意思？
如果我win10电脑自动获取dns的话
就是这样的。
如果我使用mosdns或者Adguard Home这类软件的话。
就是这样了
这个问题我在前年使用mosdns的时候就发现了，所以我不用mosdns了，然后就正常了，然后我今年用了Adguard Home，却发现还是有这样的问题，这显然是比特彗星的问题。
如果你有win10的话，也可以测试一下。win10上开这个软件和比特彗星，看看DNS查询这里是不是有问题。
稀疏文件是一个功能，就是下载资源时，以稀疏文件方式写入硬碟
如果关闭这个功能，取消下载前预分配磁碟空间功能会失效
对于64位系统运行32位，能不能加个提示弹窗，提示当前使用64位操作系统，是否进行切换提高性能，，，老是有人用32位版本运行，然后速度巨慢，导致找半天找不到问题，最后发现是运行的32位，换64位可以磁盘缓存后就正常了。。。32位直接因为调用不到磁盘缓存，任务又比较多一直几百KB/s跑不动网速
文件夹下这种说明，其实放不够醒目，建议运行BitComet.exe的时候直接弹窗，点"是"，就退出并且启动64位版本。
既然加了50%的他人共享交换种子市场，，，要不然把当前任务列表生成rss接口，用来给其他人订阅？这不是很方便吗，也方便群里大家直接订阅种子发布者的任务列表，5分钟更新一次客户端的磁力到rss.xml输出（防止上千任务时候的性能，所以5分钟同步一次），注意仅限BT任务，HTTP 和 PT任务不要放进rss.xml
包括自己多台比特彗星服务器分流种子的服务器，可以直接rss订阅自动化同步下载任务列表了
任务比较多，所以要输出支持gzip和br
http://对外ip:22223/rss.xml
图片一中的地址是有记录的
图二中BC显示故障的域名 抽取了几个测试 发现也是有记录的
可能是本地dns的问题 可以使用nslookup 命令 测试系统是否能正常解析
若找不到有效记录则为本地dns问题
反之则是BC自己的问题
Adguard Home 我也在用 不过是作为路由器上游dns使用的
可以用在线工具和 nslookup 指令测试 一下 显示为故障的dns 是否为真故障
使用nslookup 命令 可以向指定的地址发起查询
向Adguard Home 和默认dns分别发起查询 对比结果
以排除 Adguard Home 或 本地dns 的问题
改成8G最大值后，直接达到了惊人的140MB/s读取
在内存比较紧张的情况下，长效的命中率和磁盘读取活动好像有点对不上，可能是超时时间有点长？还是说1.96版本优化的一次读16M区块其实有点太大了。
还是长效下载的人太多了，，，因为我看了一下有200人，可以出个设置控制下长效的连接数来限制人数？例如默认限制30个长效TCP连接数，最小值10，最大值无限，这个限制单独针对长效上传，下载不计入限制当中。不然上传的人太多了，磁盘性能消耗有点恐怖，反而BT任务上传明明也是32MB区块，而且还连接1000多人情况，就没这么吃硬盘。
直接在这里出个设置框，长效种子最大上传连接数就可以了
关掉长效上传，只用BT任务，基本都是32MB区块的BT种子，反而没这么磁盘性能消耗，感觉可能哪里还没有优化好
让我猜一下，是不是这个问题？
BT任务是一个一个块传输的，传输完成一个块后可以立即释放内存
长效上传是基于HTTP协议多线程传输的，假设一个文件10G，A下载持续了一小时下载进度当前90%，是不是要一直占用10G内存而不释放，直到下载者断开连接才开始计算释放内存超时？导致了这个文件占用10G内存，引起B下载其它文件无法申请到内存直接去读硬盘，从而导致了磁盘性能问题
然后因为我有200个下载者，，，这个情况就更糟糕了，在服务器上好像也没办法控制客户端下载时的Range申请bytes范围，如果真有我上面猜的这个问题，我也不知道该怎么优化，要不然干脆在加个禁用缓存功能得了。。。和iis nginx kangle一样原汁原味http取文件
感谢反馈，beta2已修复
感谢建议，等有时间试一试
- 彗星未使用稀疏檔案API
- 取消下載前分配磁碟空間后，文件大小会跟随写入数据的位置而逐渐变大。
与此相关的一个选项是磁盘加速服务。未启用时，在写入文件后方分块数据时需要花费较多时间将中间区域的数据写0；启用时，中间区域的数据暂不清零，直到下载了对应分块数据再写入。
很好的建议
感谢建议，可以放到远程访问web接口里
C:\Users\Administrator>nslookup tracker1.wasabii.com.tw
服务器: UnKnown
Address: ::1
非权威应答:
名称: tracker1.wasabii.com.tw
Address: 210.244.71.25
是BC软件有问题，mosdns是我几年前用的，当时就有问题，现在的Adhome也是这个问题，DOH是用的阿里DOH和一个海外的，弄好分流了，不太可能会是DOH的问题，我用的不是路由器固件，是直接在win10上开的DNS软件，我猜测如果是把DNS软件（mosdns、Adhome）作为路由器上游dns使用，应该就没这个问题了，我猜测是关于比特彗星对win10系统底层DNS的逻辑支持有问题？
我测试了auroradns没有问题，很奇怪，我特地下了个你说的AdGuardHome，也没有发现你说的问题
这些都是死了的tracker，或者没有提供ipv4服务
你试过把DHT关掉还有问题吗，，，感觉你这个问题有点像是运营商限制了你的连接数，导致UDP发不出去，堵着了
之前反馈过个让设置个DHT最大节点数量为10个，，官方没回复我
可以去看一下AdGuardHome 的请求日志
看一下是否有请求记录以及响应情况
不过他说他上游用的是DOH
那Adhome查询发起应该用的是TCP吧？
应该要先看一下请求有没有发到Adhome
有没有可能是大量的DHT造成UDP队列过长
DNS请求还没来得及发出就因为等待时间过长判断为失败？
统计栏里DNS错误值应该是失败次数吧？
要是能看到具体的错误原因就好了
比如是请求超时还是找不到可用记录
还有建议添加 重新注册磁盘提速服务 的按钮 之前好像提过一次？
正常来说会弹出通知提示 但有时通知弹不出来
发现是Windows的通知设置里允许BC弹出通知的的开关是关着的
也许是Windows通知中心的问题？
还是设置专门的按钮会比较好 包括安装和卸载服务
以及将是否启用磁盘提速服务的选项从高级设置中移动到左侧的服务或者系统集成里
这样注册服务的按钮也有地方放了
还有upnp端口映射 如果Windows上的upnp支持服务没有运行
会报 [UPNP device not found!] 不过路由器没有或未开启 upnp也是这个错误
建议在添加时先检查并尝试启动需要的系统服务
长效做种问题
再没有任何任务的情况下依然会显示准备长效做种
右键手动移动文件，本地出现两个文件夹：
已勾选【保存torrent档案到下载目录】的情况下，移动文件后，该torrent未一起移至新目录。
用everything本地搜索，共出现两个torrent文件夹，其中一个是原路径的，包含该torrent；另一个就是移动成功的文件夹。
另外种子市场在升级之后没有了，设置里也找不到了，算是issue吗，
从1.94升到1.99和2.00，种子市场都会消失，退回重装后又会重新出现。相关设置都没变过，仅仅是升级了版本就没了。
补充：种子市场从侧边栏消失，但添加新任务的弹窗、高级设置里、仍有选项【在种子市场中共享该任务】；选择已完成的任务，右键属性、高级设置里也有此项。
种子市场交互能不能限制下数量，比如1分钟内最多接收1次交互，后续发生的交互直接拒绝交互，，，频繁交互数据库会导致磁盘写入和内存占用很高（或者已经达到我设定的10W上限后，就触发这个限制交互时间，防止占用磁盘性能，我是服务器上使用种子市场目的是把我的分享共享出去，他人分享不用都可以！）
种子市场限制10W他人分享，软件放在C盘桌面，可以发现一直在频繁写入数据库peer_shares.db
可能是因为连接了4000多个人，所以一直在超级频繁的交互数据库
peer_shares.db这个文件一直在写入把SSD占用了50%左右的性能
如果比特彗星放在D盘，D盘是做种盘，然后磁盘负荷本来就很高，如果D盘磁盘性能受限就会导致内存里torrent列表显示占用10多个G内存。
提个建议，关于【bc_bak】文件的导入。
导入【bc_bak】文件时，彗星主窗口就会【无响应】，不知是否可以避免这一情况。
比如，先把下载列表给导入了（这时候直接就能看到导入后的样子，同时也能正常操作下载列表），然后慢慢导入种子市场数据库，最后再把设置进行导入。
也许可以先将程序设置和rss订阅源导入毕竟体积小，让后将其他的内容包括种子市场开一单独线程，放在后台处理
也许可以对现有的连接控制进行细化
保留现有的全局TCP连接 和全局UDP 发包数
对具体项目进行限制
并根据项目重要程度设置优先级
这样的话就更好了，内存机器比较小的话，连接BT用户数过多会导致磁盘性能需求暴涨，今天突然来了4000人下载，可怕
只能输入9999KB
一些PT站点要求每任务限制25MB/s