其实原因是BitComet.xml和下载列表的文件烂了，停电重启后，记事本直接打开xml文件会发现尾部有一大片□的乱码字符，然后启动比特彗星无法成功读取这个烂了的文件，就导致被初始化配置文件和下载列表了
触发原因可能是停电的一瞬间正在进行保存写入xml引起的，然后这部分数据还缓存在系统内存中，没有从缓冲区刷新到硬盘里
测试过了，代码没变化，5分钟保存一次
准备改成先保存为临时文件，之后重命名为正式文件。同时保留最近3个备份，加载时从新到旧检查完整性
1個讚
把流量清零，然后启动比特彗星下载一个任务，等10分钟任务管理器结束进程，下次打开流量还是0，确实没有保存进去，你再试试？
Beta2 客户端列表工作正常了，可以正常黑白名单
客户端过滤器好像不太对，序号4默认改成禁止，，，没有直接屏蔽所有的peer
这样也不不行，把这个修一下应该就差不多了，两个功能同时互不冲突
没有添加客户端白名单规则的时候，默认目标设置为禁止时，应该和ip白名单模式一样，会封禁所有peer才正常
新加的几个客户端还没遇到，等遇到了试试有没有效果
感觉是优先级问题导致的 客户端列表的优先级似乎是高于 过滤器的
这样在默认情况下 客户端列表就放行了所有的客户端 导致过滤器被绕过了
应该将 客户端列表的优先级放到最低 这样在默认不配置过滤器的情况下
客户端列表就起到了兜底的作用 最需要调整列表就可以实现简单过滤
与之对应的 在使用过滤器的情况 由于优先级最低 其相当于被绕过
不会影响过滤器的工作
当然还有一个问题 就是手动规则和订阅规则的优先级的问题
手动规则的优先级应该高于订阅规则 再算上IP过滤器
传入客户端的过滤顺序应该为：
@wxhere15
用户传入
↓
IP过滤器（手动规则）
↓
IP过滤器（订阅规则）
↓
客户端过滤器（手动规则）
↓
客户端过滤器（订阅规则）
↓
客户端列表
↓
保持连接
目前觀察到元數據快取檔會隨時間不斷累積，
建議可比照硬碟快取機制，透過元數據重新被利用或汰舊換新的方式進行管理。同時，建議提供類似硬碟快取的容量設定選項（例如 500GB 或 1TB），以便控管元數據對硬碟空間的佔用。此外，也建議全局統計頁面除了提供元數據筆數外可再追加元數據快取命中率，方便使用者參考。」
看过代码了，不是没定时保存配置文件，而是只有退出时才会先更新累计上传、下载量再保存。我来优化一下，定时保存前也更新一下数据
感谢反馈，已修复
目前的过滤顺序为：
用户连入
↓
IP过滤器（手动规则合并订阅规则）
↓
客户端列表
↓
客户端过滤器（手动规则）
↓
客户端过滤器（订阅规则）
↓
保持连接
这里的元数据缓存文件是种子存档及种子市场里的，其数量受种子存档及种子市场各列表数量上限影响，无法单独控制。缓存命中率显然会很低很低，只有下载一次种子存档或种子市场里的磁链才会命中一次，没啥统计必要。
beta3已发布，欢迎试用
自动更新客户端筛选规则的http订阅地址哪位网友给提供一个