2.01测试版

红框里面是对齐阈值吧,本地选取的文件大于此值时才会对齐,小于就会合并到其它的块里,大概;调到0既是对全部文件对齐。

我重新制了个种拖进彗星、发现状态又对了 “已分块对齐”。或许是和我之前的设置有关系,调到1,错过了文件夹内0KiB的文件,识别为“未分块对齐”。但昨天为了测试制了好几个种,明明记得也有调到0的。

还真是这样
又测试了一下用的qbee 4.5.0.10
加些0字节大小的文件

置成0kb是没问题的但是设置成1kb就显示未对齐了


是设置为0kb
在有零字节大小文件的情况下
填充文件的位置有变化 但依然是对齐的




但设置成1kb就不行了
和设置为0的时候相比 填充文件的位置又发生了变化
bc显示为未对齐



The presence of padding files does not imply that all files are piece-aligned.

看来qb这个设置0KB的做法是跳过了某些文件的对齐

既然没有完整的全部填充文件,我觉得应当保持现状,或者给与qb的这种做法兼容性,增加一个"部分文件已分块对齐"的显示

这个问题似乎在更高的版本得到了一定程度的解决

v4.5.4 (lt20 qt6)
应该是换用lt2.0的原因
对齐边界的选项被取消了

测试结果是
使用v1时无分块对齐
使用v2时有分块对齐

qb的混合种子BC无法在BC中打开
报 “不一致的混合型种子”

qb自己可以识别 也可以识别BC的混合种子



qb不遵守bt协议去开发功能,,,问题多多,遇到问题也要多找qb的人反馈,让他们更新解决
毕竟qb是开源软件很拉稀的,和维基百科一样人人可编辑可随意编造修改内容

請問用戶列表 位置 部分缺失圖標能不能修一修?很多用戶只顯示名稱沒有圖標
已知的缺失
反饋
反饋2

image

image

image

image

下载框显示的大小应该和其它界面统一包含分块对齐的大小,需要正确显示为6.54GB

建議限速設定KB/S 和MB/S 加上保存設定…換成0之後再改…因為跳回默認是KB/S…好幾次都忘了換MB/S…

今早,占用内存暴涨,下载速度70m/s,内存占用43G,以前下载速度到过80m,也没出现过这种情况,请开发者看看是不是出现什么问题了,谢谢

设置一直没改过,不过现在内存占用下来了,因为下载速度也下来了 :rofl:

最后发现是下载盘性能太烂,下载数据全堆在磁盘写操作缓冲区了 :sweat_smile:


电脑一般是不关机的,比特彗星也是一直保持上传,软件长时间不重启就会出现上传基本没速度的情况(平时基本是7MB/s的速度),停止任务再重新开始也没速度,重启软件以后上传速度就正常了。

从去年开始遇到了快上十次吧

时代在进步,数据在在增加,换电脑是势在必行,我的4790 已经换在13700K,就是为了这个比特彗星。

自从更换到新版之后,我的绑定手机app的云服务就怎么也连不上,都是离线状态,请问大家有没有什么解决问题的方法?不会是被墙了吧(

拼寫有誤!

Java代码可以访问U盘,C++代码得root才能直接访问。暂时不改了
https://source.android.com/docs/core/storage/traditional#support_usb_media

感谢反馈

感谢反馈

有可能,手机网络不行的话,换个Wifi试试能不能连上

感谢反馈,已修复

A和B建立连接后,B传递给A自身的ipv6信息,然后A就会断开连接处于disconnected状态,然后A要等30秒才能在次请求B,能不能优化下传递自身ipv6信息后,保持连接不断开

或者,其实这是在peer交互openssl的https加密证书?

2.01至?舊版為止有bug, 不詢問直接覆蓋同名文件!
windows儲存或另存時遇上同名文件也會詢問用戶, (不是近期的)舊版BC也會詢問的!

再現1)開啟單檔案種子文件 2)儲存位置存在同名文件 3)點立即下載 4)文件被取代(即使文件大小不同)
不是沒有了舊的同名文件也沒留意(想人手比較新舊分別時,舊文件不見了(只有新的一個)), 因為以前會詢問的!
會和你說已存在同名文件要不要覆蓋, 正常動作是按取消回到前窗口手動重新命名儲存的文件名。

現在似乎要勾選hash check if file changed才會詢問, 會詢問但沒有重新命名或加上(2)(3)…之類的可選項,即是還是一個bug, 有機會覆蓋同名文件
(我需要的一直只有check(詢問)、而不需要hash。不需要hash的時候不是覆蓋、就是取消,要hash的時候會手動hash, 什麼文件不同都觸發hash根本浪費hash時間, 而且舊版的BC發生過完整性檢查會修改文件"就是將文件人為的換作其他文件再點完整性檢查後, 被更換的文件hash值被改變即被修改, 所以重來不信BC的完整性檢查(怕被錯誤修改同名文件), 能不用不開hash檢查則不用不開", 因為完整性檢查不是"唯讀")

但究竟要回退到什麼舊版本的BC才會詢問(不勾hash check if file changed),真不想一版一版試, 完全不知道期間被取代/誤刪了多少文件…

程式行為修改也不在changlog說, 之前像windows般加上(2)(3)不就好好的
即使是(純)Download Manager,任何一個, 也沒有會直接覆蓋已存在同名文件的(問也不問,名也不重名), 而且加上(2)(3)記得是以前我回報會覆蓋同名文件才有的, 為什麼不知不覺又開始覆蓋同名文件了???
希望有hotfix更新版