可以加个换行
用域名节点bootstrap的过程还是应该尽量向不同的IP多发包
是的，LSD也有发包队列控制，下一版优化一下倒计时，显示得更准确些
如果RSS种子附带的是种子文件的HTTP链接，而不是磁链，目前的代码会下载失败后重试10次，间隔1分钟，在RSS种子的任务日志里可以看到。有可能是这个原因导致下载中的队列清除得很慢。
相关设置项：bittorrent.torrent_http_try_max_count、bittorrent.torrent_http_try_interval
确实没有按照标签设置下载目录，下一版修复
今天居然没有新版
想了下 on_read_queue_finished 慢的原因，可能是启动时候要创建几千个定时器导致的卡顿
可能软件一秒只能新建两百个左右定时器，所以就导致了这个慢，然后引起界面无响应10秒
包括批量替换tracker为空产生的卡住应该也是这个原因，把定时器摧毁花了时间
感觉浪费在上下文切换，虽然2.19版本定时器优化了下性能确实好了很多，至少上次优化后大量任务运行的时候，界面不会鼠标点击右键操作一直卡住3秒延迟才弹出菜单响应的问题了
但是停止开始任务的一些界面操作时还是会无响应，感觉这个定时器估计还得优化改进一下
代码改完还要测试一下，晚一点发测试版
这个可以通过完善启动队列处理机制来优化，等下一版了
若方便的話…在種子市場下搜尋指令的時後也會導致bitcomet卡死，然後下載流量就中斷了
Beta20 已发布，欢迎试用
还是感觉可以加个高级设置，避免这种情况发生
或者自己设置1500最大连接的时候，正在发起也要改成较小的数值比如1000
算了还是别弄了，意义好像不大，用户自己改小正在发起的设置就可以了，明天可以发正式版了
就是设置1000太小了会卡住发不出去请求
-------------------之前发的时候感觉好像又不用改，我又给下面这段话删了-------------------
可不可以加个高级选项，让正在发起忽略network.max_connections的值设置
如果正在发起设置的比较高，同时限制了最大连接数的话，正在发起很容易导致把BT连接给封锁5分钟
就是和这个选项一样类似的效果，把正在发起忽略一下连接数限制
network.exclude_remote_access_from_connection_restrictions
正常情况下大概300左右，正在发起可能让已连接显示的BT或者http tracker冲到几千
限制最大已连接的目的是为了控制单台服务器的连接人数，控制内存使用率
https://bbs.itzmx.com/thread-102947-1-1.html
UDP端口监听失败
