或者能不能不要缓存在内存，直接改成sendfile方式去读取db
假设下载1000个任务，每个任务包含500个文件，那么db要记录50万的文件，而且还不能和种子市场一样限制最大值为1万，会导致db文件大小500M加载到内存
就算把这1000个任务全部删除了，文件大小还是不会变小的，如果重新下载新的1000个任务，那么文件好像还是从500M开始涨到1G
既然不是在内存里面进行读写，那还不如不要复制到内存中。
可以试一试
Bug提交：（案例：完啦，几百个的任务，打开全部消失变空白啦，怎么办啊，有什么补救措施吗？）
PS：已经远控他电脑用.bak文件进行恢复了，按照以往多次远控经验统计，这种情况往往发生在把彗星安装到机械硬盘的用户上。
故障原因：【BitComet.xml】【Downloads.xml】这两个文件在彗星启动时无法立即读取，猜测是机械硬盘忙碌。
故障已成功复现：
①在彗星开启时要加载【BitComet.xml】【Downloads.xml】这两个文件，在加载前，把这两个文件的读取权限设置为”拒绝“（模拟机械硬盘短暂忙碌），彗星因为无法读取，加载到内存的就是”默认设置、无下载任务“。
②把【BitComet.xml】【Downloads.xml】这两个文件恢复读写权限（模拟机械硬盘结束忙碌）。
③用户发现彗星设置大变、下载列表清空，就会去点击【退出】试图重启彗星，而彗星在退出时，会把内存里的”默认设置、无下载任务“保存到硬盘，彗星的设置和下载列表被彻底覆盖清空。
④当用户再次启动彗星，彗星就会加载已被覆盖清空的【BitComet.xml】【Downloads.xml】文件，彗星照样还是设置大变、下载列表清空。
改进建议：如果【BitComet.xml】【Downloads.xml】这两个文件短暂的无法读取，就多等一等，或者干脆让彗星启动失败并提示【BitComet.xml】【Downloads.xml】这两个文件无法读取。
3個讚
说起来BitComet.xml
前段时间测试发现了1.96加的每5分钟自动保存 BitComet.xml，不起效果，流量字段没有变化
<TotalUpload>0</TotalUpload>
<TotalDownload>0</TotalDownload>
配置文件消失问题的原因算是摸清楚了
意外停电后再启动配置文件消失的原因应该与也是类似的原因
目前还有遇到一个问题是意外断点 重启后BC可能会无法监听之前的端口 确定不是端口占用
已知有效的解决方法除了更换端口外应该就只有重启
在提示无法监听端口后重启2-3次似乎就能解决问题
2.15 测试版本
这里设置的是下次新建任务时的数值，当前已有任务在右键属性里面改
起的真早，收到 感谢回复。
建议增加网页音频视频嗅探功能，这样直接使用比特彗星了。 要是在能识别迅雷链接 就更无敌了。ndm 支持网页嗅探，文件蜈蚣可以参考一下。 真心建议增加。
自己很喜歡 IP 過濾器的功能，它能夠有效攔截可疑的 IP，避免無用的流量與潛在的安全風險。
建議能在全局介面中新增一行統計資訊，顯示目前載入的阻擋 IP 數量、已阻擋的 IP 次數以及整體阻擋率。這樣不僅能更直觀地了解過濾器的實際效益，也有助於評估與更新 IP 篩選清單，作為選用或更換清單的重要參考依據。
另外，自己對『替換現有 IP 位址清單』的使用方式還不是很清楚。若上傳了 4 筆清單，系統是否會以最後一筆清單取代前面 3 筆？還是有其他合併或覆蓋的邏輯？
其实可以放到全局日志里面 当然这个全局日志只有在专家模式下才会显示
关注一下····
beta2已发布，欢迎试用
1個讚
技术上没有这个“无法立即读取，多等一等”的说法。这两个文件都是程序启动时在主线程直接读取的，要么成功，要么失败，最多卡一会儿。您说的“在加载前，把这两个文件的读取权限设置为拒绝，模拟机械硬盘短暂忙碌”，并不能模拟读取失败的真实状况，因为“没有读取权限”是完全不同的错误类型，真实的读取失败原因应该是其他原因。
目前的难点在于准确重现此问题。我会在下一版全局日志里增加系统api返回的错误代码，看看能不能有点帮助。
感谢反馈，我测试一下
是程序崩溃重启吗？
这个设置项的名称我改一下，只对新任务有效
感谢建议
感谢建议
目前的替换代码比较简单，只保留最后收到的一份。可以改进成合并同一批请求的结果
客户端列表中的自定义编辑框和过滤器中的兜底规则似乎没有实装？
额 默认规则只有在添加了一条规则后才会显示
也可以在默认的情况下就显示序号为0
规则导出功能似乎有个小问题 如果规则是空的 那在导出配置文件时会提示找不到文件
而导入功能里 似乎有一个忘记删除的JSON文件名称
列表中的注释列的翻译似乎有些问题 翻译成了评论
手动规则和下载的规则也许可以改成静态规则和动态规则？
或者手动规则和订阅的规则？
规则添加窗口中的 peer监听端口 中间可以加一个空格
和上面peeID前缀 对齐
还不是 主要是意外停电后 首次启动可能会发生这种情况
除了不能监听之前的端口外其他一切正常 更换其他端口就可以正常监听
当然这个端口并没有被实际占用
通过反复多次重启系统 似乎可以解决这个问题
我换了一种方式再次复现了，这次可能更接近真实原因（掉盘）。
复现过程：
①把彗星安装在机械硬盘上，双击启动彗星后，彗星会先后加载【BitComet.xml】【Downloads.xml】这两个文件，在彗星读取这两个文件之前拔掉机械硬盘（模拟机械硬盘掉盘），彗星因为无法读取这两个文件，加载到内存的就是”默认设置、无下载任务“。
②彗星成功打开，显示为”默认设置、无下载任务“，然后把机械硬盘插回去（模拟机械硬盘掉盘恢复）。
③用户发现彗星设置大变、下载列表清空，就会去点击【退出】试图重启彗星，而彗星在退出时，会把内存里的”默认设置、无下载任务“保存到机械硬盘，彗星的设置和下载列表被彻底覆盖清空。
④当用户再次启动彗星，彗星就会加载已被覆盖清空的【BitComet.xml】【Downloads.xml】文件，彗星照样还是设置大变、下载列表清空。
（PS1：在固态U盘上也成功复现了，不过机械硬盘速度慢，更容易操作。这其实也说明了为什么往往是安装机械硬盘上的彗星出现这个故障。）
（PS2：在一次复现中，出现了“设置正常、下载任务异常”的情况（因为彗星先读取【BitComet.xml】后读取【Downloads.xml】），理所当然的，这次复现只导致了下载列表被清空。）
（PS3：问了下deepseek，掉盘原因还挺多的：电源供应不稳定、连接线路或接口问题、过热触发保护机制、硬盘老化或轻微物理损伤、系统或驱动兼容性问题。）
改进建议：如果启动彗星时，因为找不到安装所在文件夹而无法读取【BitComet.xml】【Downloads.xml】这两个文件，就说明掉盘了，让彗星自动关闭且不要更改任何文件。
这个没做，自定义功能和下面的规则列表重复了，而且这个窗口本来就是给普通用户做的简易功能，没必要太复杂。
感谢反馈，改好了
默认显示上次导出的文件名
改好了
改成订阅规则挺好的
改好了
掉盘的状况我是没遇到过，回头研究一下
1個讚
其实优化一下配置文件备份机制就行了
现在下载列表有备份了 但是程序主配置没有
遇到上述说的读取失败 后回写默认配置的情况 就没办法解决了
也许可以加个内置的配置恢复机制 可以就不用手动重命名和替换配置文件了
还有可以在高级设置中加一个调整自动备份间隔时间的选项