最终写入的tracker数量远超指定tracker列表中的数目
Closed this issue · 8 comments
当前用指定环境变量CTU的方式，指定从 https://cdn.jsdelivr.net/gh/XIU2/TrackersListCollection@master/best_aria2.txt 获取tracker，但aria2.conf中的tracker数量是301个，远超过链接中的数量。下图是放到文本编辑器中的对比，左侧为上述链接中的tracker，右侧为最终aria2.conf中的tracker
CTU仅支持RPC更新，写入本地的只有https://cdn.jsdelivr.net/gh/XIU2/TrackersListCollection/all.txt
意思是配置文件里的tracker是固定使用jsdelivr/all.txt这个列表，只有UT=true或RUT=true时在启动后或凌晨三点通过RPC更新。
其实我最开始发现问题时是通过AriaNg发现BT设置里trakcer列表有500个之多，就随手拿配置文件截图了。之前的问题应该推测应该是启动后的这次更新失败了，就一直保持config文件里的tracker
看文档中说的这意思是容器启动时会通过RPC更新一次tracker列表。
| -e CTU= | 启动容器时更新自定义trackes地址 |
|---|
1、这个描述忘了改了，因为我自己这边已经只使用RPC更新trackers了，conf文件里更新对我没太多意义，只有启动的时候会读取conf里的trackers，除了PT用户，大部分人应该都不需要
2、RPC更新trackers，每天都会进行，我这边实测没有问题
3、下次更新可能会考利让CTU支持conf更新trackers
另外aria2对bt trackers支持很弱，只会使用第一个连接成功的tracker服务器，和qb能连接全部不一样
想要提升aria2下载bt的速度
需要有公网IP
更改DHT、BT端口
满足这几点，aria2的bt下载速度还是很不错的，种子好或者任务多的时候配合SDD，可以跑满70M的速度，并且CPU占用率不高
这个描述忘了改了，因为我自己这边已经只使用RPC更新trackers了，conf文件里更新对我没太多意义，只有启动的时候会读取conf里的trackers
看起来目前行为是每次重启都会将conf里的tracker强制改成all.txt，这个问题不大，目前的问题在于启动后没有立即通过RPC修改一次tracker列表，而是要等到凌晨三点才会用CTU里的替代掉all.txt，如果启动后立即更新一次CTU指定tracker的话也不是很有必要必须通过config更新。
除了PT用户，大部分人应该都不需要
其实PT用户基本不会冒险用aria2下载，并且PT的tracker都在种子里，一般不需要用户手动在conf里手动指定
另外aria2对bt trackers支持很弱，只会使用第一个连接成功的tracker服务器，和qb能连接全部不一样
仅连接第一个成功的tracker的话就更不应该用all.txt了，best_aria2.txt会更好一些。不过如此的话tracker设置与否确实聊胜于无，不如下热门种攒一下DHT，或者在config里添加dht-entry-point
需要有公网IP，更改DHT、BT端口
这个我还是OK的，防火墙也都配置了端口转发，之前确实没想到DHT端口和BT端口居然还能共用一个。另外我发现默认生成的配置文件会禁用IPv6，实际上现在IPv6 peer也是不少的，完全可以使用 --network host来规避docker bridge的IPv6问题
对的
我这边也推荐使用 --network host，少一层nat，性能也会好很多
现在已经-e CTU= 更新conf trackers了
现在已经-e CTU= 更新conf trackers了
感谢