欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~
v2.20 正式版预览
核心修复：视频文件首尾分块无法下载时，顺序下载请求算法失效
WebUI：重新加载页面时，保留任务列表排序状态
WebUI：优化任务列表、视频文件列表各列宽度
https://download.bitcomet.com/archive/BitComet_2.20_setup.exe
https://download.bitcomet.com/archive/BitComet_2.20.zip
v2.20 Beta3 [20260116]
界面改进：任务文件列表页面增加筛选功能
界面改进：BT任务属性对话框文件列表增加筛选功能
界面改进：BT任务启用“为仅含单文件的torrent创建子目录”后，任务列表里的名称也显示为“子目录名”
核心改进：HTTP任务运行中减少连接数时，优先保留下载速度更高的连接
WebUI：视频播放文件选择窗口改为固定宽度
WebUI：视频播放文件选择窗口修复无法选中文件的问题
WebUI：顶端菜单栏里的按钮列表、任务搜索框随窗口宽度自动换行显示
v2.20 Beta2 [20260107]
界面改进：增加高级设置项：network.rss_http_visit_interval，默认100ms
WebUI：支持多行磁链批量添加BT下载任务
WebUI：任务列表采用分页加载，降低网络流量
WebUI：统计页面接口增加查询项：G_TOTAL_DOWNLOAD_BYTE、G_TOTAL_UPLOAD_BYTE、G_SESSION_DOWNLOAD_BYTE、G_SESSION_UPLOAD_BYTE
v2.20 Beta1 [20251230]
界面改进：增加高级选项 ui.copy_magnet_with_base32_infohash，设置磁链里的特征码默认编码方式
界面改进：增加高级选项 bittorrent.http_tracker，全局控制是否启用 HTTP tracker
界面改进：制作torrent文件时支持128MB和256MB分块
界面改进：高级设置项里的最小缓存大小的默认值由64MB改为256MB
界面改进：BT任务文件数量较多时，任务属性对话框里的文件顺序列表显示迟缓
核心修复：piece_part文件大小超过4GB时加载失败
WebUI：任务列表增加任务名称筛选功能
1個讚
一个功能建议：统计里的 累计下载数据/累计上传数据 能否提供以字节为单位的数据展示？
需要统计 BitComet 的流量使用情况以便自动化操作，并绘制相关图表。但 BitComet 目前会将数据格式化成人类可读格式，诸如 3.65 GB 这样。但问题在于，随着累计数据的逐渐变大，通过人类可读格式逆向计算字节单位的值精度会变得越来越差。例如到 GB 级别的时候，就已经很难统计到较小 MB 级别的变化了。如果到了 TB 级别，则会更糟糕。并且通过这种方式计算的 traffic in bytes 值会丢失精度，导致绘制出来的图表不是连续的，而是阶梯状的。需要精细计算流量信息的功能也因此失去作用，被延迟触发或者根本无法触发。
看了下现在的api，加一个bytevalue字段就好了，这样webui可以直接调用value不经过数值转化避免界面的数字需要渲染处理来回跳动
需要api的调用直接获取bytevalue的值
或者post的时候，${G_TOTAL_DOWNLOAD_AUTO_BYTE}尾部加个BYTE这样更好，可以减少api返回正常用户访问webui页面的数据流量大小
界面上新建种子
命令行新建种子
长效上传256M区块种子测试都正常工作
我试了一下，长效的最小缓存大小的值并不需要256M，只是BT区块才需要这么大
长效以前版本优化过，一次读16MB数据，然后按照64KB簇大小分块切割16MB数据为256个64KB缓存块，长效最小值保持上一版的64MB默认值就可以了，只需要改BT区块的最小值256MB
就是这个簇大小其实可以改大点了，64KB大小，如果任务多的话，在缓存了25G长效缓存时，服务器上长效分块索引会有40万个block index，也不知道有没有引入NTFS、exFAT那种类似位图技术之类，避免查找长效缓存块带来的延迟，可以试着提高到1MB，这样可以降低block index的数值，如果怕ass、txt、这些长效种子小文件多的话，，，那还是保持现状的64KB，或者提升到exFAT的默认推荐值128KB这样
我现在严重怀疑，之前提到过webui上面下载只有20MB/s的原因就是这个64KB簇大小引起的
包括长效种子传输，单线程最大值也只有20MB/s，应该就是簇大小太小，引起传输速度过慢
就是这个64KB簇大小导致了延迟，引起输出数据过慢导致下载速度变满
现在64KB=20MB/s，那么完全发挥1000Mbps需要512K，你先把这个改成512K试一下？
改了后应该也能解决现在版本在线播放报错 net::ERR_CONTENT_LENGTH_MISMATCH 的问题
磁力下载点：magnet:?xt=urn:btih:5CRIPJRNZ72NEPRYYD5IQ7SQTJLDSIJN
BitComet V2.20 Beta1 [20251230]
论坛的TLS证书覆盖范为未包括不带www的子域名
gitcode 那边提了这个建议 可以标记一下已经完成
gitcode默认没有开邮件通知需要手动设置一下
2.20 版本的帖子可以置顶一下
Linux 版本的 eMule 外掛？就像 Windows 版本一樣
我其实是觉得比起搞个彗星外置电驴，不如彗星直接内置电驴机制，或者直接去除这个外置电驴。
毕竟这原版电驴性能差，而且长期停止更新可能有安全漏洞。
eMule其实是Windows上的软件 Linux上的话要用aMule
不过都已经很多年没有更新了
不太可行 eMule 不像BT那样有BEP来规范各种请求
其似乎只能依靠对主线客户端的有限修改来实现自己功能
这可能也是eMule的非官方客户端都被称为mod的原因
此外eMule使用的是GPL开源协议 其具有传染性
如果整合的话 则BC也需要使用GPL开源
其实现在的版本默认都不带eMule插件 需要的可以自己安装
电驴不支持IP6，内置了没用 需要IP64互换才能正常用…现在大半用户都没有IP4公网，内网模式电骡效果好差。
我又试了下，目录型种子，多文件的任务长效上传的话，最小内存需要缓存是16X11（TCP10+UDP1）共176MB，看来最小值64MB应该还是不够的，那还是保持beta1的256MB吧，或者对应改成176MB默认值实现最小化占用
这人也遇到网络传输时候的主线程高CPU引起界面卡顿，2.20会着重修复这个问题吗
webUI中的任务内文件搜索功能已经可以使用
建议同步为GUI中添加上文件搜索功能
添加任务时也可以加一个搜索框
目前webUI中的 视频播放选择列表会根据文件名的长度自动调整宽度
若任务中文件较多 且文件名长度差异较大则其宽度会随着
当前显示文件名长度而不断变化 造成闪烁
建议其宽度应以该任务中文件名最长的为准 或者像GUI那样使用固定宽度
播放视频时有时会出现 invalid file_index 错误
疑似和视频播放列表选择状态有关系 多文件任务比较容易出现此问题
从请求来看 file index 的值变成了 -1
有趣的是这问题只会出现在 使用总预览按钮弹出视频选择列表的情况下
在文件列表中找到需要播放的文件 再点击其预览按钮则不会出现此问题
通过这种方法弹出的视频预览框 有时不能正确的显示 选择的文件
但下面的播放器按钮是亮起的 且能正确播放
怀疑是弹出的播放选择列表上的显示内容和实际请求的不相同
是的，我希望有一天 Bitcomet 能預裝 eMule 插件。
电驴原作者已停止开发，现在都是志愿者维护修改.预装电驴也没用 功能已过时了.
請在 WebUI 中新增功能，例如下一版本的標準 GUI：
- uTP 啟動
- 好友上傳槽
- 移除同儕
- 加入同儕
- 收到
~~~
