發現一個小問題，當檔案數量過多時，彗星未能及時建立檔案
導致系統無法開啟檔案，最終停止了正在進行的任務
建議在執行任務之前先將所有檔案建立好，然後再進行下載操作，以避免出現無法開啟檔案的問題
為了解決目前的情況，暫時的應對方法是手動將下載速率調整為1k，等待所有檔案成功建立後，再解除限制。這樣能夠確保順利完成任務而不受到檔案建立速度的限制…
关于元数据获取的疑问
在获取元数据时是否能使用 设置中的tracker服务器？
从目前的观察结果来看在未获取到元数据前是不会向任务添加tracker服务器的
不过在添加磁力时附加的tracker服务器是会被使用的
建议在元数据获取时向设置中的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.
看了你提供的2个dump文件，均是在某个文件长效上传缓存时崩溃的，其长度为 1246608706 字节。如果方便的话，可以把这个文件找出来，禁用其所在BT任务的长效上传，试试看有没有效果，以协助进一步确定崩溃原因。
会使用的。可以在种子列表选一个磁链，右键下载元数据，观察下面的任务日志
1個讚
测试了一下似乎是可以使用的
应该是之前测试时使用的客户端没有勾选此项目
事实上这两个文件是来自两个不同的用户
一个是我自己的还有另一个是一位网友的
也就是说造成我们两个崩溃的是同一个文件吗？
除了文件大小还有哪些信息吗？只有大小的话不太好确定文件
在1.2G左右的文件太多了
1個讚
错误原因分析出来了，和具体文件无关。是个别情况下的数据访问越界。下一版尽快修复。
2個讚
似乎找到了問題，原因是 SMB網路 預設對打開文件的數量有一個限制，預設值好像在 16384 左右。在編輯 smb.conf 文件時，追加了一行設置max open files = 51200，似乎已經改善了網路磁碟大量開啟檔案問題。
linux下打开文件一般设置 1048576 比较好，否则很容易出错
ulimit: open files: cannot modify limit: Operation not permitted
查看 linux 底層好像是無限制, 目前只遇到 smb 服務遇到同時開啟上萬檔案有問題, 目前任務已穩定執行不再自動停止了… 
root@nas:~# ulimit
unlimited
中英文混合,没注意,以为bug,默认中英文混合是bug,单纯是英文我还会试试看翻译