欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~
v2.19 Beta2 [20251208]
界面改进：改进监听端口错误提示
界面改进：流量图增加CPU逻辑处理器占用率
界面改进：专家模式下，统计页面显示定时器队列信息
核心改进：HTTP任务转跳时处理cookie
核心改进：升级OpenSSL到v3.5.4
核心修复：HTTP任务下载完成后，移动文件到预设文件夹失败
https://download.bitcomet.com/beta/BitCometBeta_20251208_setup.exe
https://download.bitcomet.com/beta/BitCometBeta_20251208.zip
v2.19 Beta1 [20251130]
界面改进：使用命令行参数 --bt_port 更换监听端口后，自动触发端口检测
界面改进：增加高级设置项：network.check_port_interval_hour，定时检查端口状态
界面改进：左侧边栏移除浏览器书签页面
界面修复：BT任务peer列表添加及封禁peer无法处理65535端口号的peer
核心改进：适当提升长效上传给非注册用户的上传连接数限额
核心修复：新建BT任务时，会覆盖同名HTTP任务的任务信息文件
WebUI：修复各对话框里的输入框Ctrl+A全选
WebUI：文件列表使用分页加载，降低网络流量
WebUI：文件列表显示文件优先级，并可通过右键菜单进行设置
WebUI：文件列表增加文件名称筛选功能
WebUI：优化页面缩放处理
1個讚
v2.19 Beta1 [20251130] 磁力链接：magnet:?xt=urn:btih:X4AQUMFICS6I66FDVALV5EWDRDZGMBAM&xt=urn:btmh:1220cb573be4ae64992fd8a55772808454709280527690f2e67201eb08b65bd477fe&dn=BitComet-2.19.0
仍然没有速度 你不会没有公网IP吧？…
只有一堆libtorrent/2.0.7.0吸血的…
1)種子市場下載種子A(添加到任務清單)
2)種子成功下載後 到任務清單删除該任務(勾選同時移除歷程記錄)
3)回到種子市場重新下載該種子A(添加到任務清單)
4)獲得「種子檔案開啟失敗!」的錯誤Box
由1至4全程不能關閉BC
此bug開始於2.15或2.16左右 到現在未修正
我以為這麼明顯的bug一定有人回沒有管,結果又要自己來
不是我想吐你槽, 種子開啟或下載後, archive和torrents文件夾根本在重覆佔用空間(存在兩個相同的torrents文件)
是不是應該考慮有任務存在時就只保有torrents文件夾的torrents文件, 當移除任務時才移動到archive文件夾(當選擇保留歷程記錄時)。
例如某個A開頭的防毒軟件的定義文件也是佔用兩份空間(1份軟件自用的、1份安裝程式自用的)
為什麼你們就那麼喜歡佔用多餘的存儲空間
没有人反馈过，自然不知道这个bug…我反馈过个类似的，在2.17已修复
v2.17 [Windows] [macOS] [Linux] 2025.9.28
核心修复：从种子存档打开torrent创建BT任务时，设定文件保存位置有误（修复解压文件夹下出现.temp文件）
不过进行测试了一下，你说的问题未复现
这两个地方是合理的，一个是种子存档，一个是当前任务，当前任务需要实时打开种子文件获取区块来校验，和xml记录下载数据
种子存档作用于备份和种子市场传输元数据，在任务停止或者删除的时候依旧可以正常生效，你用磁力链接添加任务能快速获取元数据转种子文件除了服务器加速外，也有这个功能的一定功劳
其它下载软件也是一样的逻辑会存储2份种子文件
上千个任务做种的情况我还真没测试过。麻烦截图看看统计页面里的 Message Queue，可以大概了解是哪些函数造成的卡顿。
为了更有效地记录、跟踪、处理bug，我在gitcode创建了一个项目，大家也可以去那里提交issue，避免论坛里所有反馈问题混杂在一起的状况。网址如下：
下载到E盘固态硬盘，确保SSD硬盘没有瓶颈，消息队列好像指向wire_handle_socket_detach_wire？软件当前仅占用2颗CPU核心，CPU核心数量为32个，只用到2个核心，CPU的利用率太低
磁力链接新建BT任务窗口卡5秒无响应，好像也是这个wire_handle_socket_detach_wire，应该是同一个原因
没有任何下载任务的话，只有做种任务时就没界面卡顿，虽然有点消息队列在里面，但是没卡顿现象
下图是正常不卡的情况（任务列表删除下载任务）
只要创建一个BT下载任务，任务列表里面只要有一个下载任务的时候，界面就开始卡死了
现在webui的下载链接是这样，迅雷在下载过程中没办法直接获取到文件名，进度达到100%才会获取header的响应信息来更新文件名
/api/file/getContent?fid=614cALPhZGahWoNBjSxpxu%2FjGx7sIoChvNk3A%2FcOPurWXUX%2BAcZcqNqpyaf04O3NxiBWVVjt9puYUWdYb2ImUGtKDuJ1GcjP5R2whnHOLHb%2FFDFu%2FdDxQH0cKd%2BmS7snCNLgB1e8pHb84nC%2FVK6S8doOiKakE7ljV2Lm1POhfb1hfQYR9U05MUDQL45HsAAP8IbA%2BgtQ%2BRkmZOauXWd0fr8%3D&mode=download
而且除了文件名问题外，现在的下载链接没办法被软件剪贴板监视接管，复制链接后无法弹出下载框
包括那个网页播放器用的链接，统一改成本地播放器链接包含文件名的那种？比如这样，然后尾部加入mode=download
/api/file/getContent/7kHTXm1urcEXHvazcP%2FJ8o8KxF3BcrfXfoQfoVUFxy5J07Cr0WSA7SfWt22LjwCsCM%2B%2FfsvBd8TvtqnJfquHrncOxNwMYW5Ztz8nZzeDfdGm00o2OOkQVQGarXU8XLNGEZ9CVVRE9XNL1gbEQjir%2Fr0fEYKz56UAk4C9X6SpRLVmGEmXJE%2B%2FF%2Bw5LssB%2BxxBAzFtJ6aZ3sxUqAHcyu1sKXg%3D/%5BNekomoe%20kissaten%5D%5BRanma%20%C2%BD%202024%5D%5B14%5D%5B1080p%5D%5BJPTC%5D.mp4?mode=download
看了一下截图里的消息队列，应该是 on_ie_event 运行了6376ms，这个函数是处理浏览器传过来的下载链接的，包括新建任务对话框显示时间。你测试时是一次打开了很多链接吗？卡5秒是在新建BT任务窗口刚显示出来，还是点击开始下载的时候？
wire_handle_socket_detach_wire是处理连接断开的函数。
我回头试试
以上测试结果都是只存在1个下载任务的情况
刚显示出来的时候卡，之前帖子上发过个动态图，通过复制剪贴板创建一个任务界面就卡
如果是用链接同时创建多个下载任务的话，同时多个下载任务是这样的
我怎么看起来是wire_handle_socket_detach_wire 的问题，因为一旦开始下载，他的消息队列数值会非常大
改成和potplayer那样就好了，链接尾部加个?mode=download就行
uTP也会触发wire_handle_socket_detach_wire 。如果开了uTP，临时关掉试试呢
服务器有公网ip，没有使用UTP，而且UTP现在版本龟速还吃CPU
如果没开uTP的话，那再看看开始下载任务后，统计页面里的TCP连接数是否有较大幅度的波动？消息队列里会持续保持大量的wire_handle_socket_detach_wire吗？
不知道这些界面卡顿问题和 进程堆的缓慢泄漏是否有关系
