测试了一下 是磁力头拼错了
v2协议的磁力头应该是"magnet:?xt=urn:btmh:"
v1协议的才是"magnet:?xt=urn:btih:"
磁力头用混了 换成v2磁力头就行
或者直接用哈希值也行
提个建议，经常有人弄混文件头【magnet:?xt=urn:btih】和【magnet:?xt=urn:btmh:】，建议在磁链识别时进行模糊判断
也就是不以文件头来区分v1磁链和v2磁链，而是直接以特征码长度进行判断，至于文件头，写成【magnet:?xt=urn:btih】或【magnet:?xt=urn:btmh:】都可以
直接用hash可以了，谢谢。
但用了v2头，提示这个：磁链错误，特征码没有找到！
你的是不是这样
magnet:?xt=urn:btmh:F30A568100F13FD3E98DA3106AF66C9EBE6E5F7186FD2ADD624A61503199D18D
并不是
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) ]
混合型种子一般要同时包含v1 v2的特征码，也就是磁力链接同时要有btih以及btmh
简单测试了一下
不一定要使用混合磁力链接
使用单独的v1或v2磁力链接
及其特征码 接都是可以成功添加的
不过这次测试还以外的发现了 彗星在元数据下载时的问题
这有点像之前提到的断点续传的问题
也和我做种时遇到的奇怪现象有些相似
但又不完全一样
测试用的是v2
彗星用的是最新的 2.04测试版
帐号登录不稳定，能不能专门给账号登陆和远程，设置一个专门的代理选项设置。
就是设置账号登陆走代理。
或者有没有其他的办法，让局部地区帐号登录稳定一点，加入些抗封锁能力。
进一步的测试发现了更多的问题
v2种子下
彗星在未获取到元数据时 显示其他客户端进度上似乎也存在问题
连接上的用户 没有本身下载进度 也没有获取到元数据 但显示其进度为 100%
同时 状态 显示为 _c_C
彗星客户端1
彗星客户端2
qb客户端
在qb上 进度显示是正确的
可能需要进一步的研究才能确定问题出在哪里
彗星使用的是最新的2.04测试版
qb的版本和之前测试时使用的相同
这种情况是正常的，代表对方有100%的元数据可以获得，而不是区块完成度
因为在本地未获取到元数据的情况下，无法得知区块进度情况
qb那个显示也不对，目前只有transmission可以正确显示元数据的完整进度（使用白条展示元数据进度）
晚些我在复查测试下元数据获取，我记得当时我测试过下载元数据的时候，并没有问题
测试避免get_torrent种子市场接口返回种子，使用内网ip做种，公网去下载元数据
和封锁比特彗星官方torrent cache服务器，使其种子下载过程只经过peer，防止直接从官方服务器上下载种子文件
封锁办法，新版Windows10设置防火墙界面有些不同，不过大致设置过程相同
https://bbs.itzmx.com/thread-95650-1-1.html
测试后无法复现v2种子元数据无法下载问题，楼主看看他问题出在哪里？
登錄框能不能增加去掉用戶的選項？
或者說怎麼去掉？
似乎这种卡元数据下载的问题只存在于混合型种子
同时在向其他客户端添加任务时只使用v2特征码时
才会出现这种问题
现象包括可以连接到qb客户端 但是下载元数据会卡进度
无法连接其他bc客户端
无论是直接连接还是tracker服务器 dht 或者 lsd 都不行
具体测试结果：
混合型种子 使用v2特征码添加任务
BC做种 qb下载 >qb卡下载元数据 似乎无法连接到做种客户端
qb做种 BC下载 >BC 卡元数据获取进度 反复重新下载元数据
BC做种 BC下载 >BC无法获取元数据 无法连接到做种客户端
qb做种 qb下载> 可以正常下载
BC在混合种子的支持上似乎存在一些问题
修改 BitComet.xml 中的PassportUserList
经过复测，问题所在应该是分块哈希上。
你也检查下是否正在获取分块哈希？
如果v2种子的分块比较多，这个过程元数据传输虽然显示完成了出现在任务列表中，但是可以发现传输分块哈希的速度会比较慢，比特彗星测试大概1秒只会传递4个分块
假如种子分块在1万以上的时候，需要等待1小时才能进行下载，期间一直会维持0KB/s，如图所示种子有40w哈希则需要27小时后才能开始下载
如果通过种子文件下载v2则立即拥有下载速度，如果通过磁力或者特征码形式添加，则需要跑这个分块哈希（每秒产生4个，种子分块哈希过多则需要等几十小时才能进行下载）
如果目前正在获取分块哈希，把种子文件拖动进任务列表中，不能立即完成分块哈希的过程，需要删除这个任务重新用种子打开
一般情况下可以连接到官方种子缓存服务器去下载种子，正常情况下是不会触发磁力下载的，是直接种子形式打开磁力链接，但是不排除某些省份因为网络因素无法连接到官方服务器，只能通过链接下载（本地可以通过系统防火墙模拟屏蔽服务器ip，ip信息可以抓包或者看我上面一楼发的帖子点历史编辑里获得）
解决方案，官方改善每秒分块哈希数值，，，不做限制，目前版本每秒4个
复现影响混合型以及纯v2种子，产生0KB的原因已找到，等官方修复
我这里的情况还不太一样
没有到分块哈希这一步
依然卡在元数据获取上 任务名和文件内容都获取不到
现在的问题是 混合种子使用v2特征码添加下载
下载的客户端连接不到 做种客户端
BC做种 BC下载
或BC做种qb下载
有趣的是 下载的各个客户端之间可以互相连接
而它们都不能和做种客户端连接
不是网络问题
使用v1特征码就没问题
将做种客户端和下载客户端对调也没有用 依然连接不上
在bc中似乎会将分别使用v1和v2特征码添加的相同混合型任务判定为两个不同的任务
这可能解释了为什么使用手动添加用户的方式依然无法连接的问题
即使在使用v1添加任务后 获取到了全部的元数据 两个任务依然是独立的
这种情况也只发生在先使用v2特征码创建任务后再使用v1特征码添加的时候
反过来是可以正常合并任务的
而在qb下这两个任务会自动合并
建议优化对特殊字符的支持
显示方面与Windows 资源管理器保持一致
遇到 不能显示的字符时不将其替换为 下划线
仅在显示时显示为下划线 不进行实际替换
如果替换会出现 找不到文件 的问题
建议添加对 Windows 长路径的支持
有考虑添加对 PROXY protocol 的支持吗？
upnp问题
群友反馈
win11专业版安装更新后 upnp映射失败
显示 Windows version not supported
在更新前是可以正常映射的
彗星的版本是2.03
检查SSDPSRV服务是否正常安装，可以尝试用管理员cmd执行
sc config SSDPSRV start= demand
1個讚