不一定要在数据库上修改，因为每一项加布尔值，数据库会变臃肿，针对数据库，非必要不加。
（现在的数据库是6项，hash，名称，大小，类型，发布时间，接收时间。）
如果非要加一项，我觉得可以加上，是否虚假，是否可下载种子。这在分享时，很重要。
特别是dht磁链市场，虚假的，无法下载种子的链接太多。
而删除的数据，其实就是黑名单，量不会太大，只要把删除屏蔽的链接，保存为一个黑名单，显示的时候不显示即可。不需要动数据库
对于varchar类型，存储数字占用一个字节，存储长度占用一个字节，因此即使数据库很大如一千万数据，也只占用10000000*2/1024/1024≈19M。
对于第一个将种子链接或文件添加下载的用户来说，肯定是可以下载的，但分享后由于时间或其他因素无法下载是正常现象。
DHT市场是基于DHT协议的，彗星作为协议遵从者，仅记录DHT交换的info_hash并展现到DHT市场里。
相比于记录黑名单并同时维护黑名单与种子数据库以及检查数据是否在黑名单里等，直接数据库字段标识是否删除是更高效的事情，查询也只需要多个where is_delete=0
没人保种，不过迅雷能下
好的，用迅雷下试试。再用彗星保种
确实可以，保存在云盘里了。下载完成后这边会放在彗星里，保种一周，不定期补种，欢迎大家一起加速
有些VPS单核心性能巨差。。。比特彗星跑起来卡卡的。四核心跑分还没家里一核心快。。。坐等后续版本改善支持多核心
预先创建和CPU同等数量的线程数，然后每个外部远程新连入连接分配到不同的工作线程。。如果本地发起也可以做分配，那性能会更好。
最好可以高级选项自定义，默认0自动分配，可手动设置
自动分配情况，对于特殊情况，例如如果是英特尔i5 9400f之类的6核心6线程cpu，6大于4则分配8线程。
刚下完，放进去了，随便搜索个什么都三四十秒，还伴随偶现的卡住
以下为python测试
SELECT Count(*) FROM PeerShares;
SELECT * FROM PeerShares where title like ‘%中国%’;
控制台大概16秒
sqlite3大概12秒
SELECT * FROM PeerShares where title like ‘%女%’;
python sqlite3大概18秒
如果作者大佬想继续优化种子市场大数据的话，加上分页跟查询限制limit是一个很好的选择，不过感觉没有太大必要，有这个精力不如优化优化下载
啊，我1600频率的内存条，七代i5，搜索也就15秒左右啊，是不是没换1.93版的彗星，1.93版的彗星在种子市场的速度上提高不少
就是1.93版的呀，我掐的秒表计时误差应该不大
那就不知道了我这边的群友用着也是十几秒，会不会是高级设置的io优先度有影响
设置的非常低。你呢
【普通】，官方默认就是【普通】，不是【普通】的话，有时候有些操作会很慢
22：18崩溃了，日志已发请查看
22：22再次崩溃，错误日志已发
22：25又崩溃了，日志已发
我退出了，睡觉去
BUG，该选项对BT任务，magnet磁力下载不起效果
感谢反馈，错误报告看过了，是种子列表按评论数排序时出现的崩溃。取消排序或改成其他排序可暂时避免。
对于这个问题我建议出个新的选项，同时下载的元数据任务最大数目
提个建议，关于【反吸血】功能
【反吸血】的作用是在【一定的时间内，如果下载者不提供一定的上传量，就关闭与对方的连接】。
但【反吸血】没有这样的作用——【在一定的时间内，如果自己不提供一定的上传量给上传者，就自觉关闭与对方的连接】
觉得这应该是相互的，就像彗星如果屏蔽了某种客户端的下载，就得屏蔽某种客户端的上传一样。否则就是只利于自己的“吸血”行为而已（指对bt大环境吸血）。
举个例子，我设定【1秒内，如果下载者不提供10KB的上传量，就关闭与对方的连接】,就能安然做吸血鬼了。（我知道彗星圈子好人多，但吸血鬼也绝对不少）
所以我的建议是，当开启【反吸血】功能的时候，也以同等标准对待自己，“反”自己的“吸血”。
不同意你的想法。。。