欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~
v2.21 Beta1 [20260426]
界面改进：增加高级选项 bittorrent.transfer_thread_pool，使用工作线程进行BT传输加密解密运算，默认关闭
界面改进：流量图里的CPU使用率统计增加“BT传输线程”类别
界面改进：BT任务用户列表添加peer对话框支持行首//注释
WebUI：优化任务列表和文件列表的分页加载
https://download.bitcomet.com/beta/BitCometBeta_20260426_setup.exe
https://download.bitcomet.com/beta/BitCometBeta_20260426.zip
bittorrent.transfer_thread_pool 不起作用？而且感觉比2.20卡多了，还随便操作几下就崩溃了两次，难道是错觉？我重启服务器试试
好吧，不行，感觉界面卡卡的，而且2.21beta1一直崩溃，无法正常使用，发送了10几份崩溃报告上去了
错误报告已收到，看了一下，是触发了新加的工作线程里进行加解密运算的状态检查保护代码，在某些情况下还需要做额外的处理。下一版修复
建议在UTP选项后添加 实验性 字样以防止用户意外开启
添加个提示，不如直接把utp的问题给解决修复了，从根源上解决问题（拖更好久了）
能解决当然是最好的 但是现在的问题找不到卡住CPU的原因
居然还没找到吗？之前讨论时不是发现是一直在低效复制数据吗，应该是 KeSynchronizeExecution 和 KiCheckForKernelApcDelivery 的问题
````````````````````````````````````````-`````````````````````````````````````````````````````
还有之前提到的，定时器虽然优化了不少，但是也可以放在工作线程
等验证吧 说不定还有别的的问题呢
磁力分载点：magnet:?xt=urn:btih:X2WVYH5SBFPYH2VOWLLT2ZE3TJRSQTZL&xt=urn:btmh:1220004faff13de05e7af250aea84b0dd6151e47dd1864a2bbd4d33114224d862953&dn=BitComet%20V2.21%20Beta1%20%5B20260426%5D
請問長時間下載后 BC占用大量内存不釋放
目前除了重啓BC還有更好的辦法嗎
經常看到全部任務都關閉后内存占用都還是在4G以上
网站上显示这个是tracker服务器返回的，该功能已有，切换到服务器选项卡就可以查看了
https://bbs.itzmx.com/thread-111853-1-1.html
可能是长时间运行累计较多的种子市场数据，切换到统计分类看看内存是什么原因占用，如果是种子市场可以限制一下最大数量100000，避免消耗太多的内存
v2.21 Beta1你们能正常使用吗？我不论默认关闭bittorrent.transfer_thread_pool的情况，还是开启，都会一直崩溃
可以參考網頁版的呈現方式，直接在種子清單中顯示相關資訊。(彗星)目前僅能在下載或上傳任務中，逐一切換至追蹤器頁面查詢，使用上較不直觀且效率偏低。此外，現有的「熱門」標示缺乏數字化指標，無法清楚反映實際熱度，相較之下不如直接顯示 seed、leech 數量來得直覺明確。
彗星下載 http 功能, 檔案會漏資料是什原因?
目前使用版本
下載續傳顯示正常
使用 7zip 解壓縮
就會出現錯誤
檔案也會不全?
若使用 Chrome 瀏覽器直接下載
檔案解壓縮是正常
那可以让官方在种子市场做个帖子上介绍的scrape功能
设置个scrape服务器用于查询，tcp或者udp均可
比如给某个tracker服务器打"星标"代表使用这台服务器作为scrape
udp查scrape的话，毕竟没有utp那种自动mtu检测，考虑到穿透mullvad或者的类似软件
使用udp查询scrape，确保组合一次发送≤66个hash查询，udp包内容在1352内（1360-udp包8=1352实际数据），20字节一个hash+scrape包头16字节，66个hash的情况下=1336字节
使用tcp查询，由于url长度限制2048，确保发送≤25个hash查询，每个hash占用71字节，路径与协议包头开销20字节，剩下的253字节预留给域名dns长度
感觉是多线程的问题的 我这边只协商到单线程 下载的文件没有问题
浏览器下载是单线程的也没有问题
你这个链接复现解压不了的情况
单独使用302跳转后的域名去多线程下载没有问题，任选其中一个直接去多线程下载都正常
https://ia800107.us.archive.org/zip_dir.php?path=/0/items/jacky-cheung-gold-collection-k2hd.zip&formats=FLAC
https://ia600107.us.archive.org/zip_dir.php?path=/0/items/jacky-cheung-gold-collection-k2hd.zip&formats=FLAC
但是用主域名链接 archive.org 去下载就出问题了
下了个 Beyond Compare 比较了下数据，左侧失败，右侧解压正常，看起来缺少一些字符
看了您的建議，感覺會增加開發者麻煩並非自己本意，主要是我對「熱門」欄位的呈現方式還不太理解。實際使用上，大部分情況似乎都不會有燈號顯示。
我想釐清的是：這個燈號本身是否具有「是否可下載」的參考價值？還是只是補充資訊？另外是否有進一步優化的空間？
我有稍微測試過，隨機下載一個標示為熱門的項目，但卻沒有燈號顯示；
進一步查看 tracker 資訊後，實際上是有不少 seed 的。
在 BitTorrent 生態裡，其實使用者最直覺在意的只有一件事：「這個東西能不能下載？」
而不是精確到有 137 個還是 142 個 seed。
因此我覺得「熱門燈號」本身是很好的概念，也很直覺易懂。若能強化至關重要給出第一顆燈號的判斷（例如是否可下載 / 是否存活），會更有實際意義；至於燈號數量多寡，則比較偏向影響下載速度的參考資訊。
