2.06测试版

比如aria2就没法用peerid来屏蔽,所以需要上面说的客户端字符串匹配检测

請問數據元緩存吃掉好幾G記憶體是什原因?

是否是數據元下載消化不良影起?

看起来是等待太多了,有几百万个等待下载,试试把下载中改成1000

收到,沒想到DHT種子訊息湧入有如洪水,看來自己的設定可能有些過於寬鬆了, 非常感謝您的說明…

image

其实我说的是这个,改成1000后可以加快下载过程。截图看到你现在是10

不过你在DHT市场上限制最大数量也可以
torrent_share.max_metadata_dl_task

1個讚

1个bug,任务列表中选中多个任务右键长效做种的启用和禁用是无效的,单任务属性中的允许长效种子上传选项会变更状态,但是在长效做种文件中没有生效,需要重新勾选该选项才会生效。

之前反馈过,,还没修复

發現一個小問題,當檔案數量過多時,彗星未能及時建立檔案

導致系統無法開啟檔案,最終停止了正在進行的任務
image

建議在執行任務之前先將所有檔案建立好,然後再進行下載操作,以避免出現無法開啟檔案的問題
image

為了解決目前的情況,暫時的應對方法是手動將下載速率調整為1k,等待所有檔案成功建立後,再解除限制。這樣能夠確保順利完成任務而不受到檔案建立速度的限制…

image

1個讚

关于元数据获取的疑问

在获取元数据时是否能使用 设置中的tracker服务器?


从目前的观察结果来看在未获取到元数据前是不会向任务添加tracker服务器的


OUH1R8B~XETUB%JCEXUFF4_tmb

不过在添加磁力时附加的tracker服务器是会被使用的
DUXZ~HMM6_7X7T$YH26%}2

建议在元数据获取时向设置中的tracker列表里的服务器请求用户
从而加速元数据获取的过程

这样在bc的元数据辅助获取服务器不可用时 获取用户的速度应该也能比纯DHT网络更快

对tracker服务器的请求也只是发送哈希值并接收用户列表和已经获取元数据的任务相同

注意这里说的是在元数据获取阶段同时向设置列表中的tracker服务器请求用户
而不是直接向tracker发送元数据下载请求

这应该是符合协议规范的 在BEP0009规定了 磁力链接中tracker服务器部分为可选
而在没有指定任何tracker的情况下应该使用DHT网络

xt is the only mandatory parameter. dn is the display name that may be used by the client to display while waiting for metadata. tr is a tracker url, if there is one. If there are multiple trackers, multiple tr entries may be included. The same applies for x.pe entries.

dn, tr and x.pe are all optional.

If no tracker is specified, the client SHOULD use the DHT (BEP 0005) to acquire peers.

该功能已有,勾选此选项后,添加元数据下载过程,才会自动查询tracker加速获取,如果没有勾选这个功能,就不会自动添加tracker
image

看了你提供的2个dump文件,均是在某个文件长效上传缓存时崩溃的,其长度为 1246608706 字节。如果方便的话,可以把这个文件找出来,禁用其所在BT任务的长效上传,试试看有没有效果,以协助进一步确定崩溃原因。

会使用的。可以在种子列表选一个磁链,右键下载元数据,观察下面的任务日志

1個讚

测试了一下似乎是可以使用的
应该是之前测试时使用的客户端没有勾选此项目


事实上这两个文件是来自两个不同的用户
一个是我自己的还有另一个是一位网友的

也就是说造成我们两个崩溃的是同一个文件吗?
除了文件大小还有哪些信息吗?只有大小的话不太好确定文件
在1.2G左右的文件太多了

1個讚

错误原因分析出来了,和具体文件无关。是个别情况下的数据访问越界。下一版尽快修复。

2個讚

2.07测试版已发布,欢迎试用

似乎找到了問題,原因是 SMB網路 預設對打開文件的數量有一個限制,預設值好像在 16384 左右。在編輯 smb.conf 文件時,追加了一行設置max open files = 51200,似乎已經改善了網路磁碟大量開啟檔案問題。

linux下打开文件一般设置 1048576 比较好,否则很容易出错
ulimit: open files: cannot modify limit: Operation not permitted

查看 linux 底層好像是無限制, 目前只遇到 smb 服務遇到同時開啟上萬檔案有問題, 目前任務已穩定執行不再自動停止了… :slightly_smiling_face:

root@nas:~# ulimit
unlimited