如果分块没校验通过会被丢弃，点任务日志查看…
可能与高级设置bittorrent.separate_sources_for_failed_piece有关~
已经改成否了，但依然不行。坚持到100G，直接删了种子和已经完成下载的部分。
测试了一下，一次下载完成。如果出现一直无法完成的状况，可以先看看任务日志，是不是有peer在上传错误数据。另外可以尝试停止任务再重新启动，看看能不能完成下载
你不是个例，没用的。受不了，就反手一个迅雷脱离苦海吧
根据你的描述，分析应该出在web seed上，因为这个选项是仅针对bt用户列表的peer起效果
目前不知道web seed是如何判断的，你检查下状态这一栏，web seed中是否有错误的信息？
展开分块错误，里面能观察
目前发现个比较严重的问题，，，web seed的range特别小，是使用512KB 或者1MB发起的，而不是跟随BT区块或者是直接使用16MB范围
http://45.145.43.68:11113/%E3%80%90%E9%AB%98%E6%B8%85%E5%BD%B1%E8%A7%86%E4%B9%8B%E5%AE%B6%E5%8F%91%E5%B8%83%20www.WHATMV.com%E3%80%91%E7%99%BD%E8%9B%87%EF%BC%9A%E6%B5%AE%E7%94%9F%5B%E5%9B%BD%E8%AF%AD%E9%85%8D%E9%9F%B3%2B%E4%B8%AD%E6%96%87%E5%AD%97%E5%B9%95%5D.White.Snake.Afloat.2024.2160p.WEB-DL.H265.DDP5.1-SONYHD/%E7%99%BD%E8%9B%87.%E6%B5%AE%E7%94%9F.White.Snake.Afloat.2024.2160p.WEB-DL.H265.DDP5.1-SONYHD.mkv
直接提取链接后用HTTP方式下载是正常的，对方web服务器限制了禁止国外访问和限制ip并发35线程，可能是这个原因?
由于发起的请求特别小，然后频繁关闭与新建打开服务器线程，触发了web服务器35线程数限制引发503错误，然后导致获得了503状态码的错误数据，引起区块校验失败
不过web seed发起有带长连接头，虽然服务器可能不认，纯HTTP下载发的是Connection: close
Keep-Alive: 300
Connection: Keep-alive
我建议把这个弄大点，，，，不然线程速度还没提上去，就被TCP关闭了，服务器都还没来得及调整TCP窗口大小，提升socket缓存之类，就被客户端强制断开了导致下载速度变慢，特别表现在跨国传输的时候，一次应该至少传输16MB的数据，这512KB字节发起的范围，，，下载都龟速
补充
看了下抓包，对方的web服务器是符合HTTP协议RFC规范认这个Connection头的，收到close后会关闭连接并且响应close，如果长连接则根据协议不回应头
只要把range改大，应该就能解决这个问题了，或者和长效种子一样，客户端发起的时候和区块对应，这个种子是8M区块，发起的range就是8M
就和m3u8 hls一样，切片的文件太小，会严重影响视频播放速度，因为加载跟不上，单个.ts文件越大在线播放缓冲越快越流畅
从图上看到视乎是有判断busy自动重试的，看来不是这个原因引起的数据校验失败丢弃了，不过对于range确实要改大
不知道彗星有没有qb的限制上传窗口这种功能或者是我的上传会优先提供给我更高上传的用户？
xtreme 有上传通道设置，而且整个软件只提供最大16k上传速度，这就妥妥的是一个电驴吸血客户端了
原版就是那个排队机制比较恶心，，，没什么大问题
不会啊，我的可以跑到几 MB/s，跑不到是设置有问题。
如果你的上传>500，并且发现Xtreme的上传不是很稳定的时候，请在 prefercence.ini 中找到 “sendbuffersize=####” 这一行，并将这一行修改为“sendbuffersize=24000″，使用24k发送缓存。在大部分情况下，它能改善大水管的上传能力。
电驴官方的电驴现有版本已经内置了多套反吸血机制，包括积分文件，队列排队等等，详细资料和文档可以在官方找到
这个文档也是很旧的了，最后一次更新是 14.02.2011 7:48。反吸血机制最晚 0.50a 都已经有了，实际上应该更早。原版的反吸血对新的吸血手段无能为力（有用，但不是很有用），比如像下面这种有问题的 mod string，我用的 eMule v0.50a Xtreme 8.1：
2024/10/15 10:45:30: Bad MODSTRING- Client 218.156.199.247 ‘http://emule-project.net’ (eMule v0.47f,None/None/None)
2024/10/15 17:00:32: Bad MODSTRING- Client 183.97.93.50 ‘http://emule-project.net’ (eMule v0.47f,None/None/None)
此外比较常见的还有 corrupt userhash（错误的用户哈希），原版 eMule 对此根本无能为力。
目前版本可以使用状态功能，正在连接代表是没有上传的任务，不过有个上次活动时间是更好一点，比如3小时前有发生过流量
在早期确实尝试过类似的方法 也包括在Windows上设置NAT
但这些实验的效果都不太理想 无法实现目标
最接近成功的是使用hyperv虚拟机的NAT功能
不幸的是其似乎只对虚拟网卡有效
好在我们现在已经有了解决方法
那就是使用路由器设备上的upnp功能
应该是魔改版本，已经有好些站点禁用qb了，因为会重复汇报数据
NexusPHP1.5 如PT客户端有V4V6地址，做种汇报数据问题
https://bbs.itzmx.com/thread-110216-1-1.html
2024-10-17 08:24:29 schedule next announce in 2:00:00
比特彗星客户端tracker的时间能不能弄长几分钟，120分钟的tracker返回±6分钟随机差分的话，会在 117-123分钟 这样，如果正好是加法，那就强制变成120分钟了，导致加法不起效果，比如比特彗星值从120改成123，便于起效果。。。
但是现在家宽上传限制比较严重，所以不可能无限制上传.如果只有我1个人上传的话，限制上传分享率低一些感觉会导致死种问题。感觉qb的这种功能存在有他的合理性。
话说大佬.10的解锁版啥时候出来？ 