或许可 手工改,
没试过.
使用 Resource Hacker
可以看到.
我觉的 BitComet 可以把这搞成 活的, 让 用户 自己加.
例如:
Flags.ZIP 内包含
CN.png
US.png
TW.png
CA.png
…
这样确实方便 emule也是这样搞的
不过彗星是合成了一个完整文件 用的时候再切
这样改起就很麻烦
应该说 BitComet 1 人 没空搞,
那交给 全世界 的人 来搞,
简单多了.
其实改成emule那种DLL形式就行 方便自定义
改哪种都行,
问题是 BitComet 愿不愿意接受建议,
我现在都懒的建议了.
还是建议种子市场的列表，能不能给个SysListView32控件的字体大小调节选项，现在的界面中的字体不可调，时间看久了，眼睛就累，还有可不可以设置表格行的背景色，比方说隔一行显示不同颜色，这样比较清晰。
这样横纹容易引起视觉疲劳，纯色反而不会，如果要做请提供选项开关。
不是不愿意 毕竟是个免费软件 以前有团队，现在好像就楼主一人 那点广告收入恐怕要忽略不计
让人用爱发电有点那啥了
除了修bug 和必要的功能之外 其他功能只能往后放放了
做成像qb这样淡色的就可以了
允许用户选择是否开启
使用客户端名称封禁的方法确实可以有效解决目前遇到的
peer ID 固定部分小于6个字符的客户端
但是还是建议添加支持正则表达式的peer ID 封禁功能
可以参考一下qbee使用外置配置文件 但不使用固定路径
在高级设置中添加一个选项 允许用户自定义屏蔽列表文件的位置
同时建议加入一个定时重载屏蔽列表的选项 默认时间为0 即不定时重载
可由用户自定义
你盯着这张图看十几秒，在最小化返回桌面或者看其它的地方，是不是眼睛里出现了横纹
其实现在的屏蔽客户端名称解决了问题就行，屏蔽指定客户端或peerid不是最终解决办法，费力做这个正则不如改善对于BT任务做种状态的反吸血，一次性从根底更智能的解决问题
目前反吸血只能对下载任务起效果，做种状态的都是黑白名单了，需要引入一个反吸血，帖子上面反馈那套应该能用来试试
BitComet BTv2 的种子无法在种子市场里通过双击直接下载（元数据下载失败，解析错误），v2.06 v2.07 已测试均存在该问题
2.05及后续版本才支持，种子存档、种子市场、RSS种子列表测试都没有复现你说的问题，DHT种子列表及Tracker种子列表由于协议限制无法支持
建议减少默认设置中每秒并发UDP数量 以及UDP队列长度
过多的UDP发起对家用路由器的压力非常大 容易影响整体网络稳定性
基本不存在这个问题，如果使用带ssh的路由器可以观察top任务管理器的占用情况
出现问题主要是小部分运营商限制了宽带TCP/UDP并发连接数
如果设置上减少这个数值会导致udp阻塞发送引起内存泄露，永远卡在缓冲区里导致占用几十个G内存无法释放，目前队列只能丢弃dht，还有tracker，dns等都是会阻塞的
遇到问题关闭禁用DHT基本可以解决大部分问题，包括高级设置提供了禁用udp tracker选项，也可以打开，此时udp产生的流量基本只有dns了
找到复现办法了，但是我想这可能不是很好解决
复现在A端使用2.04版本，B端使用2.07，B端收到的信息不包含v2特征码
A端截图：
B端截图：
如果A端使用2.05版本，那么B端是可以正常取得元数据
A端（角色：Server）版本 2.07
B端（角色：Client）版本 2.06或2.07
B端在种子市场里面 直接双击下载一个它来自A端独有且从未下载过的 纯BTv2 种子
B端可以看到 被截断的特征码 v1 和 完整的特征码 v2 ，开始任务秒失败，报解析错误
确实复现了，直接手动复制特征码是可以正常的，但是双击打开不行
v2种子有问题，混合型种子没问题
应该是v2种子不应该传输被砍断的v1特征码（v2种子截断的v1信息视乎是正确的，以便不同版本种子市场支持），这个v1特征码也没办法获取到元数据
或者应当修复一下，v2种子使用截断的v1特征码可以正常传输元数据才行
还有个问题，混合型种子无法直接通过v2特征码获取到peer，tracker对于混合型种子应当分别向两个特征码进行汇报
B端手动添加A端的ip地址和端口可以获得元数据，所以混合型种子应当同时对2个特征码汇报给tracker
是指那个判断公网的建议？
很不幸这个问题广泛存在 若使用默认参数
我想我说的是普通用户和普通设备
以及刚接触软件的人 他们没有兴趣来排障
其实还没到运营商这一步
巨大的UDP发起量就已经把家用路由器或者光猫冲垮了
现在确实只能这样 至于根治的方法可以考虑设置发起优先级
或者分为不同的发送队列 但这样的改动可能比较大 短时间搞不好
很遗憾这不是默认设置
等遇到问题 用户考虑的恐怕就不是解决问题
而是换软件了
这其实也是在安利彗星的时候的一个比较大的问题
默认参数还是要保守一些会比较好 不然把用户都吓跑了
不是那个，那个想法纯粹是为了发种可以高速出种，提高分流效率
反吸血是这个
巨便宜的50块钱tp千兆路由器，udp小包承受能力都是16W pps，何来光猫或者路由器卡死一说，只能说他被运营商限制了，但是不了解他自己被限制了，所以自己以为觉得是路由器出问题了
正如你说的，并不知道真正的原因是被运营商限制
可以翻一下以前的帖子，当时network.max_udp_pkt_per_sec默认设置比较小，然后就导致内存大量积累在UDP 传输缓冲区，经过内存调试分析发现在DHT和大量的udptracker上引起阻塞，也有很多相关的反馈，然后就调大了，你可以自己试一下把数值改成10，是不是会发现全部积累进去缓冲区了，然后就发送阻塞加内存泄漏了，不过现在版本DHT支持队列丢弃，稍微有一些好转了，但是tracker还是会引起udp阻塞的
但这确实影响了他们正常上网
之前是正常的 开了软件就不正常了
在怀疑运营商和软件之间他们会先怀疑谁呢？
即使他们发现了这是运营商的问题
但他们在 和运营商较劲与 关闭软件 这两个选项中又会作何选择呢？
而且这样高的发包量容易被认为是“不正常”的
我还是这个观点默认传输参数应该保守一些
有需求可以自行调高
我也说了现阶段只能这样
至少这样可以在软件开启后多坚持一段时间
要根治的话 还是应该控制DHT包的产生
而不是加大队列或者丢弃队列
在做种阶段 向对端发送下载请求真的符合标准吗？
感觉有些奇怪