现在是在主线程完成hash检查，然后post到工作线程里写盘
好的，可以试试
問下你，視頻步進不開關鍵幀就會卡卡，換上千讀寫的SSD會不會正常？
灰化效果和编辑功能已经可以正常使用了
目前的订阅功能包括 tracker订阅 IP过滤器以及客户端过滤器
其用于填写订阅URL的文本框支持多行似乎可以支持订阅多个链接
有些用户也是这样使用的 似乎也没有什么问题
这在tracker和IP过滤器中其实也不是个问题 因为其本身就是无序排列的
但是在客户端过滤器中就不一样了 其是JSON格式
所以现在的这些订阅功能是否支持同时订阅多个链接？
不开关键帧的话，上万的ssd都会卡的，因为一次性会读取整个视频文件，如果视频10个GB，那么拖动一次读10个GB，关键帧启用的话一般读15MB，为了保证流畅关键帧是必须设置打开的
我想想还有什么高负载的场景在主线程，比如上传读盘的时候校验也是一个吧？
[读盘] → [hash检查] → [上传]
还有下载完成作为长效种子完整性检查和手动完整性检查时候，都放进去工作线程里吧
客户端过滤器的规则列表无法合并，填写多个订阅链接只会保留最后收到的一个
大部分情况下上传分块时无法额外做一次hash检查，默认数据已经检查过了。只有新建任务或修改任务保存目录时，检测到同名文件，且选择了跳过整个任务的Hash检查，才会在上传分块时对未检查过的分块数据先进行一次hash检查。
是无需吧？那挺好，还以为上传的读盘时候还要校验一次，总之这些有可能吃cpu的场景都放工作线程里
这么说来tracker和IP订阅是支持多个订阅地址的 可以加个提示 就像代理选项卡那样
客户端过滤那边可以把订阅框改成单行的 高度也改低
beta5已发布，欢迎试用
英文界面的文字里下载地址是加了复数的，中文看不出来。不过输入框高度暗示了可以输入多行
好的
1個讚
和测试版无关的吐槽回复
BitCometTracker 0.5 Built on Feb 5 2007
居然检测代码里写死Total Memory Usage＞2048MB就自动崩溃，实际上任务管理器看进程并没有占用那么多内存
所以TCP Active Sockets Threads数值最多设置为800，启动软件后空载占用为1100MB，剩下的内存留给peer
实际上进程占用176MB的情况，，，软件内显示占用1260MB
现在是10分钟间隔随机下发（差分技术挺好的），不能自己设置成2小时，想用点闲置服务器的流量，还是重装个系统跑opentracker吧
测试完毕，一会就面临要2GB了（实际上800M），测试晚高峰需要15分钟定时重启一次进程才能解决崩溃问题
这个tracker服务端用来做测试还是挺不错
也许可以稍微更新一下？添加个IPv6支持什么的
毕竟是2007年的的软件了 太久没有更新了
之前问过，这套源码都搞丢了，没办法更新了，除非重新开发一套新的了，opentracker很满意就是没Windows版
比较严重的问题就是崩溃，和Threads给少了会引起TCP丢包，晚高峰TCP Active Sockets维持在6000左右，但是Threads只能给到800，因为阻塞那TCP丢包率非常高
3389端口丢包率为0%
8080端口丢包率为50%
opentracker 吗？
2048MB内存崩溃和TCP丢包指的是 BitCometTracker 0.5 啊
opentracker是没有任何问题的（它tcp只能支持单核心其实算一个问题）
如果是这样的话BC的tracker拿来做测试还是够用的
2007年的tracker代码还在，不过很多依赖项接口都变了，要重新编译还得花些功夫
那其实也不着急 用于测试已经足够了
其实 BitCometTracker 还发现个问题。。。A种子、B下载两者正常是这样，B能看到A的ip
但是在B上面右键执行二次更新tracker，会额外返回2个不存在错误的peer，虽然不影响正常使用，但是多出2个不存在的肯定是有bug
看来还是重装个Linux系统跑 opentracker 吧，毕竟编译起来太麻烦了，，，也没几个人在用估计
WebUI：新建HTTP任务窗口默认连接数上限改为2000
这个是不是会有些激进了？抛开大量并发连接对源站会瞬间施加大量负载不说（即使是 4C 的 AMD EPYC-Milan 服务器同时处理 1000 并发都会被施加极大的压力）。更不用提内核本身的连接数限制和软中断开销了。
如果 BitComet 这样滥用连接数请求，除了对源站造成冲击以外，在普及后很有可能会被 CloudFlare 视为 HTTP DDoS 被拉进托管规则的。如果对象是对象存储或者 CDN 也很容易触发并发请求数限制而拒绝连接。
我真心希望这个默认值可以调整为 16，如果需要更大的可能只是需要存储到 localStorage 中记住，而不是暴力的 2048 连接数。
如果是我的下载服务器遇到这样大并发的用户或者客户端，我肯定会毫不犹豫对这类请求全部返回 403。