1.66测试版

好像一个一个选改小不会卡那么久,选了他人共享改小后,然后立即马上选择DHT改小。。。就一直卡好久好久了
估计太大了,,好几百MB
image

数据库格式是 sqlite 吗?曾经从一个超过 1G 的 sqlite 数据库中删除一个几百万条的表,卡了一天多没反应,最后只好新建一个数据库把其它的表拷过去,除了要删除的表

是啊,可以放到工作线程

对,以前是xml的,现在改成sqlite了,现在的db比以前的xml性能提高很多,不过还是不大如意,sqlite是支持多核心线程的不知道怎么跑的单核心。估计开发难度比较高。
官方文章也写了是多线程支持的
https://www.sqlite.org/faq.html#q6
(6) Is SQLite threadsafe?

Threads are evil. Avoid them.

SQLite is threadsafe. We make this concession since many users choose to ignore the advice given in the previous paragraph. But in order to be thread-safe, SQLite must be compiled with the SQLITE_THREADSAFE preprocessor macro set to 1. Both the Windows and Linux precompiled binaries in the distribution are compiled this way. If you are unsure if the SQLite library you are linking against is compiled to be threadsafe you can call the sqlite3_threadsafe() interface to find out.

SQLite is threadsafe because it uses mutexes to serialize access to common data structures. However, the work of acquiring and releasing these mutexes will slow SQLite down slightly. Hence, if you do not need SQLite to be threadsafe, you should disable the mutexes for maximum performance. See the threading mode documentation for additional information.

Under Unix, you should not carry an open SQLite database across a fork() system call into the child process.

加载、保存、排序、刷选查找已经多线程了,删除还没来得及改

Beta8发布了,修复部分反映的问题

立馬升級 Beta8… 多謝!

多谢开发者积极修复问题

DHT市场元数据下载改成1000视乎会影响性能?
正常情况
image
等我再测一下看看,刚才修改没有重新打开软件,等待队列有9W多个了,当时速度直接掉到7MB/S。
现在重开软件只有很少的DHT了,,过段时间再看看
image

新版 DHT 感覺優化不錯, 成功率提升不少…

Beta8

Beta7

另外這版的網路磁碟 IO 暴增, 之前只有在算哈希才會高流量… 新版好像隨時在算哈希?
test5

连接数太多了,可能速度上不去?

如果任务状态是下载中,那应该不是在哈希检查。“下载前预先分配磁盘空间”是不是默认打开的呢?

现在观察了一下目前没遇到之前的情况了
DHT种子市场内存溢出也没了,工作正常

1個讚

有打開…

不過從路由器跟實體機看不出有什流量異常… 請忽略這問題… :slight_smile:

不知道1.66的有生之年能不能把長效快取歸入到快取設置了… :rofl: :rofl: :rofl:
現在長效一直設定10KB/S上傳有點難受…長效真的是好東西…

又被無視?

從往後BC的更新日志中的修改項目可證,我説的都是對,我先説的,但卻被無視

_____________ ↓____
1)所有下載|下載中|完成|未完成|運行中

在BC上新增磁鏈,保持磁鏈在未完成下載狀態下重啟BC後,未完成分頁上並没顯示有此磁鏈任務。

2)例,有兩個BT任務使用相同文件名(不同hash但同名字)
一個是在1年前已完成的下載,另一個是今天新增的磁鏈,儲存在相同的位置
當磁鏈完成下載該種子後,會不由分説地直接取代相同名字的文件,由零開始…

3)同時任務數隨時間減少

(設定)同時下載的BT任務最大數
(全局統計)執行中: (執行中的數目會隨時間減少)

假設同時下載的BT任務最大數設定為10,任務中等待下載的磁鏈為200
下載隨着時間,以上等待中的磁鏈不斷被完成和開始下載,超出任務最大數的任務會保持等待中
隨時間,磁鏈會先後被完成,下載任務不斷完成和開始新的任務,超出最大數的任務繼續保持等待中

但同時下載的BT任務數目卻不明白地漸漸減少,例如最大任務數設定為10,但同時執行中的任務漸漸降到4
如更改設定中的同時下載的BT任務最大數為16,同時執行中任務上升為10,將最大數量降低也是相對的減少

感谢反馈。不好意思,单独发的帖子没看到 :sweat_smile: 相关问题已记录,后续版本会改进的

单独发帖容易被忽视,帖子里回复的话好像比较容易被看到

右键-清理-仅删除未完成的下载档案,貌似有个BUG:
我某个任务,主文件(电影)用旧版Bitcomet在几个月前已经下载完成100%,更换版本后任务列表里面没有,想长效做种而添加任务,结果变99.9%,把推广文件全部勾选后挂了很久也没下载完成,就使用“右键-清理-仅删除未完成的下载档案”,结果把电影主文件等全部删除,只剩下一个.torrent文件,不知道这是不是个BUG 。

99.9%是任务总进度,要看一下文件列表,会把文件列表里不是100%的文件都删掉。很可能是因为缺少的广告文件造成相邻电影视频文件头尾分块不完成,无法通过哈希检查,造成进度不是100%。


运行48小时,工作良好好,没有内存溢出现象了

就是,,,有时候还是不会超时啊,麻烦帮忙看下是什么情况,是不是界面导致计时器卡了
大部分超时是能正常的,,但是突然一不能超时就出毛病了,,


也不知道是不是对方网站有什么特殊的毛病,,如果挂的是utorrent那么rss下载种子文件却是正常的

bt任务的peer超时是没有问题了,可以正常超时释放链接。
就rss的http下载种子文件超时可能有毛病。就卡在那,也不释放了,也不进行重试