黑暗模式不改进下么 是真的太丑了 线条也很刺眼
建议为设置界面添加滚动条以适应低分辨率屏幕或较低的窗口高度
可以参考qb在内容可以完全显示的情况下不展示滚动条 有遮挡时显示滚动条
感谢提醒，beta2已修复
如果windows默认的dns查询得到的ip是loopback地址，彗星会再次向OpenDNS查询，以避免DNS污染。但如果用户手动修改hosts文件设置指定域名为loopback地址，win11下的API会被忽略。为应对这种特殊情况下的个别需求，添加了这个高级选项，一般用户用不着去修改。
现有的UI框架下很难精确控制深色模式的显示效果。下载任务列表里的线条可以点击主菜单 - 查看 - 任务列表 - 显示网格线 关闭。
感谢建议
在高分辨率和高缩放下软件内的部分图标似乎存在显示问题
部分图标显示大小不正确 如底部状态栏图标
有一个问题就是我这里的opendns的ip被封了，我的win10上设置了Adguard Home，但是dns查询错误特别多，似乎是软件支持方面有问题？我的比特彗星使用环境也是win10，同一台电脑开的这2个软件，adgu上设置的无污染doh，
国内确实封了opendns的，我这里用这个dns也是被封的，这个功能主要对国外用户有用吧，国内用不上反而可以关掉，或者应当改为doh去双重查询，例子使用cf作为反代服务器解决谷歌doh国内被封问题
cf workers反代代码 已经设置代码框可以复制使用了
addEventListener('fetch', event => {
event.passThroughOnException()
event.respondWith(handleRequest(event))
})
/**
* Respond to the request
* @param {Request} request
*/
async function handleRequest(event) {
const { request } = event;
//请求头部、返回对象
let reqHeaders = new Headers(request.headers),
outBody, outStatus = 200, outStatusText = 'OK', outCt = null, outHeaders = new Headers({
"Access-Control-Allow-Origin": reqHeaders.get('Origin'),
"Access-Control-Allow-Methods": "GET, POST, PUT, PATCH, DELETE, OPTIONS",
"Access-Control-Allow-Headers": reqHeaders.get('Access-Control-Allow-Headers') || "Accept, Authorization, Cache-Control, Content-Type, DNT, If-Modified-Since, Keep-Alive, Origin, User-Agent, X-Requested-With, Token, x-access-token, Notion-Version"
});
try {
//取域名第一个斜杠后的所有信息为代理链接
let url = request.url.substr(8);
url = decodeURIComponent(url.substr(url.indexOf('/') + 1));
//需要忽略的代理
if (request.method == "OPTIONS" && reqHeaders.has('access-control-request-headers')) {
//输出提示
return new Response(null, PREFLIGHT_INIT)
}
else if(url.length < 3 || url.indexOf('.') == -1 || url == "favicon.ico" || url == "robots.txt") {
return Response.redirect('https://baidu.com', 301)
}
//阻断
else if (blocker.check(url)) {
return Response.redirect('https://baidu.com', 301)
}
else {
//补上前缀 http://
url = url.replace(/https:(\/)*/,'https://').replace(/http:(\/)*/, 'http://')
if (url.indexOf("://") == -1) {
url = "http://" + url;
}
//构建 fetch 参数
let fp = {
method: request.method,
headers: {}
}
//保留头部其它信息
let he = reqHeaders.entries();
for (let h of he) {
if (!['content-length'].includes(h[0])) {
fp.headers[h[0]] = h[1];
}
}
// 是否带 body
if (["POST", "PUT", "PATCH", "DELETE"].indexOf(request.method) >= 0) {
const ct = (reqHeaders.get('content-type') || "").toLowerCase();
if (ct.includes('application/json')) {
let requestJSON = await request.json()
console.log(typeof requestJSON)
fp.body = JSON.stringify(requestJSON);
} else if (ct.includes('application/text') || ct.includes('text/html')) {
fp.body = await request.text();
} else if (ct.includes('form')) {
fp.body = await request.formData();
} else {
fp.body = await request.blob();
}
}
// 发起 fetch
let fr = (await fetch(url, fp));
outCt = fr.headers.get('content-type');
if(outCt && (outCt.includes('application/text') || outCt.includes('text/html'))) {
try {
// 添加base
let newFr = new HTMLRewriter()
.on("head", {
element(element) {
element.prepend(`<base href="${url}" />`, {
html: true
})
},
})
.transform(fr)
fr = newFr
} catch(e) {
}
}
for (const [key, value] of fr.headers.entries()) {
outHeaders.set(key, value);
}
outStatus = fr.status;
outStatusText = fr.statusText;
outBody = fr.body;
}
} catch (err) {
outCt = "application/json";
outBody = JSON.stringify({
code: -1,
msg: JSON.stringify(err.stack) || err
});
}
//设置类型
if (outCt && outCt != "") {
outHeaders.set("content-type", outCt);
}
let response = new Response(outBody, {
status: outStatus,
statusText: outStatusText,
headers: outHeaders
})
return response;
// return new Response('OK', { status: 200 })
}
/**
* 阻断器
*/
const blocker = {
keys: [".m3u8", ".ts", ".acc", ".m4s", "photocall.tv", "googlevideo.com"],
check: function (url) {
url = url.toLowerCase();
let len = blocker.keys.filter(x => url.includes(x)).length;
return len != 0;
}
}
我的无污染DOH是正常的，但是电脑用了mosdns或者Adguard Home这种DNS软件之后，比特彗星的DNS查询会报错
是指统计中的DNS故障吗？
如果是的话 可以将报错的域名复制出来
使用其他工具进行查询
以确定其是否存在有效记录
若有记录则为BC的问题
若无记录则为域名本身的问题
bitcomet不支持稀疏檔案吧？
所以取消下載前分配磁碟空間不起作用
看不明白，能不能用简体解释下是什么意思？
如果我win10电脑自动获取dns的话
就是这样的。
如果我使用mosdns或者Adguard Home这类软件的话。
就是这样了
这个问题我在前年使用mosdns的时候就发现了，所以我不用mosdns了，然后就正常了，然后我今年用了Adguard Home，却发现还是有这样的问题，这显然是比特彗星的问题。
如果你有win10的话，也可以测试一下。win10上开这个软件和比特彗星，看看DNS查询这里是不是有问题。
稀疏文件是一个功能，就是下载资源时，以稀疏文件方式写入硬碟
如果关闭这个功能，取消下载前预分配磁碟空间功能会失效
对于64位系统运行32位，能不能加个提示弹窗，提示当前使用64位操作系统，是否进行切换提高性能，，，老是有人用32位版本运行，然后速度巨慢，导致找半天找不到问题，最后发现是运行的32位，换64位可以磁盘缓存后就正常了。。。32位直接因为调用不到磁盘缓存，任务又比较多一直几百KB/s跑不动网速
文件夹下这种说明，其实放不够醒目，建议运行BitComet.exe的时候直接弹窗，点"是"，就退出并且启动64位版本。
既然加了50%的他人共享交换种子市场，，，要不然把当前任务列表生成rss接口，用来给其他人订阅？这不是很方便吗，也方便群里大家直接订阅种子发布者的任务列表，5分钟更新一次客户端的磁力到rss.xml输出（防止上千任务时候的性能，所以5分钟同步一次），注意仅限BT任务，HTTP 和 PT任务不要放进rss.xml
包括自己多台比特彗星服务器分流种子的服务器，可以直接rss订阅自动化同步下载任务列表了
任务比较多，所以要输出支持gzip和br
http://对外ip:22223/rss.xml
图片一中的地址是有记录的
图二中BC显示故障的域名 抽取了几个测试 发现也是有记录的
可能是本地dns的问题 可以使用nslookup 命令 测试系统是否能正常解析
若找不到有效记录则为本地dns问题
反之则是BC自己的问题
Adguard Home 我也在用 不过是作为路由器上游dns使用的
可以用在线工具和 nslookup 指令测试 一下 显示为故障的dns 是否为真故障
使用nslookup 命令 可以向指定的地址发起查询
向Adguard Home 和默认dns分别发起查询 对比结果
以排除 Adguard Home 或 本地dns 的问题
改成8G最大值后，直接达到了惊人的140MB/s读取
在内存比较紧张的情况下，长效的命中率和磁盘读取活动好像有点对不上，可能是超时时间有点长？还是说1.96版本优化的一次读16M区块其实有点太大了。
还是长效下载的人太多了，，，因为我看了一下有200人，可以出个设置控制下长效的连接数来限制人数？例如默认限制30个长效TCP连接数，最小值10，最大值无限，这个限制单独针对长效上传，下载不计入限制当中。不然上传的人太多了，磁盘性能消耗有点恐怖，反而BT任务上传明明也是32MB区块，而且还连接1000多人情况，就没这么吃硬盘。
直接在这里出个设置框，长效种子最大上传连接数就可以了
关掉长效上传，只用BT任务，基本都是32MB区块的BT种子，反而没这么磁盘性能消耗，感觉可能哪里还没有优化好
让我猜一下，是不是这个问题？
BT任务是一个一个块传输的，传输完成一个块后可以立即释放内存
长效上传是基于HTTP协议多线程传输的，假设一个文件10G，A下载持续了一小时下载进度当前90%，是不是要一直占用10G内存而不释放，直到下载者断开连接才开始计算释放内存超时？导致了这个文件占用10G内存，引起B下载其它文件无法申请到内存直接去读硬盘，从而导致了磁盘性能问题
然后因为我有200个下载者，，，这个情况就更糟糕了，在服务器上好像也没办法控制客户端下载时的Range申请bytes范围，如果真有我上面猜的这个问题，我也不知道该怎么优化，要不然干脆在加个禁用缓存功能得了。。。和iis nginx kangle一样原汁原味http取文件
感谢反馈，beta2已修复
感谢建议，等有时间试一试
- 彗星未使用稀疏檔案API
- 取消下載前分配磁碟空間后，文件大小会跟随写入数据的位置而逐渐变大。
与此相关的一个选项是磁盘加速服务。未启用时，在写入文件后方分块数据时需要花费较多时间将中间区域的数据写0；启用时，中间区域的数据暂不清零，直到下载了对应分块数据再写入。
很好的建议
感谢建议，可以放到远程访问web接口里
C:\Users\Administrator>nslookup tracker1.wasabii.com.tw
服务器: UnKnown
Address: ::1
非权威应答:
名称: tracker1.wasabii.com.tw
Address: 210.244.71.25
是BC软件有问题，mosdns是我几年前用的，当时就有问题，现在的Adhome也是这个问题，DOH是用的阿里DOH和一个海外的，弄好分流了，不太可能会是DOH的问题，我用的不是路由器固件，是直接在win10上开的DNS软件，我猜测如果是把DNS软件（mosdns、Adhome）作为路由器上游dns使用，应该就没这个问题了，我猜测是关于比特彗星对win10系统底层DNS的逻辑支持有问题？
