2.04测试版

安卓版rss处能否加个全选批量下载 和 批量复制磁力的选项,避免一个一个点击去创建任务

建议优化对特殊字符的支持
显示方面与Windows 资源管理器保持一致

遇到 不能显示的字符时不将其替换为 下划线
仅在显示时显示为下划线 不进行实际替换
如果替换会出现 找不到文件 的问题


建议添加对 Windows 长路径的支持


有考虑添加对 PROXY protocol 的支持吗?

upnp问题
群友反馈

win11专业版安装更新后 upnp映射失败
显示 Windows version not supported
在更新前是可以正常映射的
彗星的版本是2.03


检查SSDPSRV服务是否正常安装,可以尝试用管理员cmd执行
sc config SSDPSRV start= demand

1個讚

解决了
还真是 服务的问题

比如360一键优化,就会把这些系统服务禁用掉,可能是用了这些“优化软件”导致的

要是彗星在添加upnp映射时能检查依赖服务就好了

建议在添加upnp映射时尝试启动 必要的Windows服务

同时建议在高级设置中添加 请求管理员身份的选项
以防止在修改upnp服务 和添加磁盘提速服务时 出现权限不足的情况

能不能调整一下mac版本的状态栏图标的大小呢,看着很突兀
Snipaste_2023-09-27_21-00-51

感谢提醒,beta2已修改

感谢反馈,beta2已添加

感谢反馈,beta2已修复

1個讚

卡0%进度的问题好修吗,应该是加快传递就能解决了吧?

我看到更新日志,请问是只修复了混合种子?那纯V2种子这样怎么办呢?我是做种人,连到了很多这样的客户端,种子大小6GB,使用最新的测试版进行做种,其他人也还是这样,
这些客户端的标志位基本都是P H
image

他们的状态是_c_C
1{D_GDJNZ9~0SM%LXA21D4J
,该种子的磁力链是magnet:?xt=urn:btmh:12202fd3bcb7800cb5338180497ed83da84cdbefff9b28713f1787ca3511d34c8511

这种情况似乎只出现在纯v2种子中
一些用户没有下载进度 状态显示都是 _c_C
即对我的数据不感兴趣
而我的进度是100%

使用qb下载似乎不存在这样的问题
而在彗星中也不是100%发生 但几率也很高
可能在特定的条件下才会发生
这个问题似乎已经存在了很长时间 从1.7X 到2.03 都会出现这个问题

继续求优化多核心效率,目前所有BT软件都是单核心的,不支持多线程,要是比特彗星能率先支持多线程就好了,只跑单核心容易吃主频,导致G口宽带无法完全发挥出来


测试了一下,应该是界面显示不完善造成的误解。

纯v2种子元数据组成结构与v1不同,其info节点内不包含分块hash,仅包含每个文件的根hash。而每个分块的hash使用了新的hash tree结构,位于元数据的piece layers节点内。因此元数据的下载过程可分为2个步骤,首先下载info节点内的文件列表,之后再下载文件对应的piece layers数据。目前彗星仅显示了元数据步骤1的下载过程及进度,步骤2的过程没有明确的显示,要等步骤2完成后才开始真正下载文件数据。

其它软件可能将元数据下载步骤2与文件数据下载穿插在一起同时进行,所以没有明显的步骤2。彗星目前的设计是优先完成元数据下载步骤2再开始下载文件数据,目的是首先获取该文件完整的piece layers数据后计算出文件根hash,并与步骤1里的文件根hash进行比较,从而确保分块hash的有效性。之后再开始下载文件分块数据,也就可以及时验证每个文件分块数据的有效性,不用等到下载完整个文件后再验证文件根hash,从而避免下载了大量无效数据而无法验证的风险。

下一版将增加元数据下载步骤2的相关进度显示。

2個讚

界面改进:增加警报提示:磁盘写缓存过大

这个提示只在软件内的通知,没有在Windows10操作中心中弹出通知
image

看我上面的测试,是分块哈希导致的,因为在比特彗星中,一秒只能传输4个哈希,,,所以就一直卡0%

测试文件下载方式能不能增加Resilio Sync和微力同步

如果只是界面显示问题的话应该不会影响下载吧?
但是这些用户已经卡0% 好几天了
应该是在传输上确实遇到了困难

这种情况要在文件非常大的情况下会发生和我遇到的情况还不太一样
不能确定对方是已经获取到了元数据但卡在了分块哈希上
还是连元数据都没获取到

我觉得分块哈希的可能性不大

需要进一步的测试

建议在种子为纯v1或者v2时
复制特征码中的另一选项应被禁用


没必要吧?批量复制的时候又要保持现状不变
可以只对单任务起效果