2.04测试版

[wxhere15]

欢迎下载测试版，尝试新功能。请大家多提反馈意见，感谢各位支持~

v2.04 正式版预览 20231016
界面改进：增加弹出通告：磁盘写缓存过大
界面改进：Win10操作中心通知显示APP图标

https://download.bitcomet.com/archive/BitComet_2.04_setup.exe
https://download.bitcomet.com/archive/BitComet_2.04.zip

v2.04 Beta4 [20231011]
界面改进：torrent v2任务文件列表显示piece layer哈希下载情况
核心修正：torrent v2任务在获取piece layer哈希之前不应启动长效下载及eMule下载
核心修正：测试版未启用peer日志查看功能

v2.04 Beta3 [20231001]
界面改进：任务列表选中单个BT任务时，根据种子文件版本灰化右键菜单里的复制infohash命令
界面改进：专家模式下新增高级选项 log.bt_peer，启用后peer列表右键菜单可查看peer日志
界面改进：对于v2或Hybrid格式的种子文件，peer列表状态栏显示分块Hash下载进度
核心改进：对于v2或Hybrid格式的种子文件，增加Hash请求队列长度

v2.04 Beta2 [20230928]
界面改进：通行证登录窗口用户名下拉列表添加【全部清除】命令
界面改进：全局选项下载目录页面增加选项，任务完成后自动移动文件时，移动子目录内的全部文件
核心修正：Hybrid种子文件任务不接受infohash v2创建的任务的连入
核心修正：Hybrid种子文件任务使用infohash v2创建任务后，下载元数据失败

v2.04 Beta1 [20230915]
界面改进：增加警报提示：磁盘写缓存过大
界面改进：任务列表、任务摘要、任务磁盘信息里的BT任务剩余大小不再包含分块边界填充区域的大小
界面改进：改进Fluent风格皮肤图标配色
界面修复：免安装版使用APP_DATA目录里的配置文件时，加载Fluent皮肤失败
核心修正：改进解析混合型 torrent 文件的兼容性，处理最后一个文件是padding文件的情况

macOS版 v2.4.1
https://download.bitcomet.com/mac/BitComet_2.4.1.dmg

Linux内测版 v2.4.2
下载链接在此页面

[jiwawa181]

2.04沒看到皮膚有啥改進
倒是說下比較離譜的問題
全部都太白了
例如這個任務洗選器，選擇後顏色沒啥區別的
就是能不能圖標按下去後，變成綠色

今天就是這個問題出問題·
我關機前，按完成度排序
開機後，因為窗口被資訊欄擋住，只看到完成的100%的任務
我以為自己在完成的頁面，慣性的刪除任務，沒想到自己其實在
所有任務頁面，把未完成的都刪除任務
搞得又得導入一次，一個小時
我的天啊！

[bolivia]

尝试下载这个混合种子的时候，我把它的v2 hash贴进BC里，提示：“URL格式错误”，下载不了。
magnet:?xt=urn:btih:F30A568100F13FD3E98DA3106AF66C9EBE6E5F7186FD2ADD624A61503199D18D
这个问题有点普遍，不知道算不算问题，还是特性。我把它粘贴进其它支持混合或v2的客户端里也是没法识别/下载。
但纯v2的链接就正常，BC可以下载。

https://www.file.io/xmlA/download/Cs9XwaWMrjsG

[ie12]

测试了一下 是磁力头拼错了

v2协议的磁力头应该是"magnet:?xt=urn:btmh:"
v1协议的才是"magnet:?xt=urn:btih:"

磁力头用混了 换成v2磁力头就行
或者直接用哈希值也行

[3118244273]

提个建议，经常有人弄混文件头【magnet:?xt=urn:btih】和【magnet:?xt=urn:btmh:】，建议在磁链识别时进行模糊判断

也就是不以文件头来区分v1磁链和v2磁链，而是直接以特征码长度进行判断，至于文件头，写成【magnet:?xt=urn:btih】或【magnet:?xt=urn:btmh:】都可以

[bolivia]

@ie12

测试了一下 是磁力头拼错了

直接用hash可以了，谢谢。
但用了v2头，提示这个：磁链错误，特征码没有找到！

你的是不是这样
magnet:?xt=urn:btmh:F30A568100F13FD3E98DA3106AF66C9EBE6E5F7186FD2ADD624A61503199D18D

[ie12]

并不是

magnet:?xt=urn:btmh:1220f30a568100f13fd3e98da3106af66c9ebe6e5f7186fd2add624a61503199d18d

似乎在v2规范中要在 哈希值前面加上 1220

所以v2完整的磁力头 应该是 “magnet:?xt=urn:btmh:1220”

BitTorrent info hash (BTIH)
These are hex-encoded SHA-1 hash sums of the “info” sections of BitTorrent metafiles as used by BitTorrent to identify downloadable files or sets of files. For backwards compatibility with existing links, clients should also support the Base32 encoded version of the hash.[3]
xt=urn:btih:[ BitTorrent Info Hash (Hex) ]
Some clients require Base32 of info_hash (e.g., Vuze).

BitTorrent info hash v2 (BTMH)
BitTorrent v2 replaces the obsolete SHA-1 hash with a SHA-256 info hash. The v2 info-hash is given a new prefix (btmh) to allow for torrents that can participate in both v1 and v2 swarms[7]
xt=urn:btmh:[1220: (v2 prefix) BitTorrent Info Hash (Hex) ]

[zhuxiaoying85309]

混合型种子一般要同时包含v1 v2的特征码，也就是磁力链接同时要有btih以及btmh

[ie12]

简单测试了一下

不一定要使用混合磁力链接

使用单独的v1或v2磁力链接
及其特征码 接都是可以成功添加的

---

不过这次测试还以外的发现了 彗星在元数据下载时的问题
这有点像之前提到的断点续传的问题
也和我做种时遇到的奇怪现象有些相似
但又不完全一样

测试用的是v2
彗星用的是最新的 2.04测试版

做种时遇到的奇怪现象

自己做了一个种子 种子格式使用 纯v2 上传时发现有很多的用户进度一直卡在 0 而且也没有上传速度 仔细观状态发现 这些客户端的状态 都是 _c_C 即对我的数据不感兴趣 但这些用户都没有进度 而我的进度是100% [bc-2] 换用qb也是类似的情况 [qb-2] 怀疑和 v2种子有关系 也可能是这些客户端 没能下载元数据 bc似乎不支持 元数据的断点续传 但获取元数…

1.97测试版

[image] 元数据下载进度不能保持吗，出现断开后，，，又从0%开始了。 [image] [image] 测试了其他的BT软件，例如transmission 会保持进度，而且支持多个peer对元数据进度累计共享，peer1获取10%，peer2获取50%，peer3获取40%，从而获得一个完整的元数据，而且获取元数据的时候有一个明显的白色进度条 [image] 这个元数据获取问题麻…

[yugf6690274]

帐号登录不稳定，能不能专门给账号登陆和远程，设置一个专门的代理选项设置。
就是设置账号登陆走代理。
或者有没有其他的办法，让局部地区帐号登录稳定一点，加入些抗封锁能力。

[yheon]

這版語言檔沒改進上次講的啊？

[ie12]

2.04测试版

简单测试了一下 不一定要使用混合磁力链接 使用单独的v1或v2磁力链接 及其特征码 接都是可以成功添加的 不过这次测试还以外的发现了 彗星在元数据下载时的问题 这有点像之前提到的断点续传的问题 也和我做种时遇到的奇怪现象有些相似 但又不完全一样 测试用的是v2 彗星用的是最新的 2.04测试版 [动画]

进一步的测试发现了更多的问题
v2种子下
彗星在未获取到元数据时 显示其他客户端进度上似乎也存在问题
连接上的用户 没有本身下载进度 也没有获取到元数据 但显示其进度为 100%
同时 状态 显示为 _c_C

彗星客户端1

彗星客户端2

qb客户端
在qb上 进度显示是正确的

可能需要进一步的研究才能确定问题出在哪里

@zhuxiaoying85309 @wxhere15

彗星使用的是最新的2.04测试版
qb的版本和之前测试时使用的相同

[zhuxiaoying85309]

@ie12

也没有获取到元数据 但显示其进度为 100%

这种情况是正常的，代表对方有100%的元数据可以获得，而不是区块完成度
因为在本地未获取到元数据的情况下，无法得知区块进度情况

qb那个显示也不对，目前只有transmission可以正确显示元数据的完整进度（使用白条展示元数据进度）

晚些我在复查测试下元数据获取，我记得当时我测试过下载元数据的时候，并没有问题

[zhuxiaoying85309]

测试避免get_torrent种子市场接口返回种子，使用内网ip做种，公网去下载元数据
和封锁比特彗星官方torrent cache服务器，使其种子下载过程只经过peer，防止直接从官方服务器上下载种子文件
封锁办法，新版Windows10设置防火墙界面有些不同，不过大致设置过程相同
https://bbs.itzmx.com/thread-95650-1-1.html

测试后无法复现v2种子元数据无法下载问题，楼主看看他问题出在哪里？

[jiwawa181]

登錄框能不能增加去掉用戶的選項？
或者說怎麼去掉？

[ie12]

似乎这种卡元数据下载的问题只存在于混合型种子
同时在向其他客户端添加任务时只使用v2特征码时
才会出现这种问题

现象包括可以连接到qb客户端 但是下载元数据会卡进度
无法连接其他bc客户端
无论是直接连接还是tracker服务器 dht 或者 lsd 都不行

具体测试结果：
混合型种子 使用v2特征码添加任务

BC做种 qb下载 >qb卡下载元数据 似乎无法连接到做种客户端
qb做种 BC下载 >BC 卡元数据获取进度 反复重新下载元数据
BC做种 BC下载 >BC无法获取元数据 无法连接到做种客户端
qb做种 qb下载> 可以正常下载

BC在混合种子的支持上似乎存在一些问题

[hz6615997184904]

修改 BitComet.xml 中的PassportUserList

[zhuxiaoying85309]

@ie12

同时在向其他客户端添加任务时只使用v2特征码时

经过复测，问题所在应该是分块哈希上。
你也检查下是否正在获取分块哈希？
如果v2种子的分块比较多，这个过程元数据传输虽然显示完成了出现在任务列表中，但是可以发现传输分块哈希的速度会比较慢，比特彗星测试大概1秒只会传递4个分块
假如种子分块在1万以上的时候，需要等待1小时才能进行下载，期间一直会维持0KB/s，如图所示种子有40w哈希则需要27小时后才能开始下载

如果通过种子文件下载v2则立即拥有下载速度，如果通过磁力或者特征码形式添加，则需要跑这个分块哈希（每秒产生4个，种子分块哈希过多则需要等几十小时才能进行下载）

如果目前正在获取分块哈希，把种子文件拖动进任务列表中，不能立即完成分块哈希的过程，需要删除这个任务重新用种子打开

一般情况下可以连接到官方种子缓存服务器去下载种子，正常情况下是不会触发磁力下载的，是直接种子形式打开磁力链接，但是不排除某些省份因为网络因素无法连接到官方服务器，只能通过链接下载（本地可以通过系统防火墙模拟屏蔽服务器ip，ip信息可以抓包或者看我上面一楼发的帖子点历史编辑里获得）

解决方案，官方改善每秒分块哈希数值，，，不做限制，目前版本每秒4个
复现影响混合型以及纯v2种子，产生0KB的原因已找到，等官方修复

[ie12]

@zhuxiaoying85309

经过复测，问题所在应该是分块哈希上。
你也检查下是否正在获取分块哈希？

我这里的情况还不太一样
没有到分块哈希这一步
依然卡在元数据获取上 任务名和文件内容都获取不到

现在的问题是 混合种子使用v2特征码添加下载
下载的客户端连接不到 做种客户端
BC做种 BC下载
或BC做种qb下载

有趣的是 下载的各个客户端之间可以互相连接
而它们都不能和做种客户端连接
不是网络问题
使用v1特征码就没问题
将做种客户端和下载客户端对调也没有用 依然连接不上

在bc中似乎会将分别使用v1和v2特征码添加的相同混合型任务判定为两个不同的任务
这可能解释了为什么使用手动添加用户的方式依然无法连接的问题
即使在使用v1添加任务后 获取到了全部的元数据 两个任务依然是独立的

这种情况也只发生在先使用v2特征码创建任务后再使用v1特征码添加的时候
反过来是可以正常合并任务的

而在qb下这两个任务会自动合并