好的，看到你单独发的帖子了，明白你的意思了。回头改一下。
如果任务启动时发现文件修改日期发生变化，会将其所有分块标记为黄色。提示检查时，可以选择暂不检查，等黄色分块需要上传给其他用户时再自动检查。如果要只检查黄色分块，界面上得设计一个选项了。请问你主要是在程序异常退出后会需要哈希检查吗？
谢谢反馈。最近版本一直在优化性能，减少卡顿。
不清楚檔案哈希检查邏輯, 目前遇到的困擾…
進階選項, 都是使用預設值…
-
停止的任務, 分塊全部是藍色…
-
啟動任務後, 就開始漫長的 0%~100% 驗證, 該任務看分塊全部還是藍色? 並無[修改日期发生变化，会将其所有分块标记为黄色]等動作?
停止後再重新啟動任務, 就回到以上1)~2)項目還是藍色區塊
所以才會想說, 是否支援 [完整檢查黃色分塊] 即可, 藍色就跳過, 加快完整驗證時間? 保有完整驗證功能
以上例子, 正常退出後, 重啟任務就開始跑 0~100% 哈希检查 (小檔沒感覺, 大檔檢查很殺時間)
还有一种可能，和文件改动无关：如果没有禁用长效上传，而种子文件不是彗星制作的，没有包含长效上传的信息，那么全部文件下载完成后会自动扫描一遍计算长效上传信息。可以把长效上传暂时关掉试一试。
哈! 真的耶, 禁用长效上传就好了, 老大有沒有兩全其美方法? 禁用长效等於 Bitcomet 自我封印… @@"
这个暂时想不到好办法了。长效上传的机制和BT不同，和电驴类似，需要单独再计算一次哈希。
如果启用了电驴插件，一次扫描最多会计算3种哈希。
计算哈希需要完整扫描。如果是文件修改日期变化造成出现黄色分块，可以选择暂不扫描呀。
問一下…
能不能增加獨立任務快取設置…
有些文件很大…但超龜速基乎斷種的霸佔了全快取…(沒有其他任務進行中…
不然下次加任務又要改回去(自動快取設置…
cache有自动替换算法，访问较早的会自动失效被替换掉的。
你誤會我的意思了…
我的意思是
零上載+低速下載 = 霸佔了CACHE的空間…也就是沒用但又佔用了大量記憶體不作任何用途
需要手動打開動態CACHE他會釋放到256MB左右
但下次下新種又要重新打開那個功能…不然上載獨狂讀盤.
我想你指的是低速下载的任务占用了cache空间。这种情况如果下载新种子，低速任务的cache空间会自动被高速任务替换掉。如果不下载新种子，确实不会被释放，有可能会影响系统里的其他程序使用内存。是这个问题吧？
差不多吧…
明白了。目前只有缓存不足时，以及任务停止时才会释放失效的cache。可以考虑改进算法主动释放长时间未访问的cache。
不好意思請教一下, 本人對哈希觀念薄弱(完全不懂), 只會看圖說故事, 剛提到计算3种哈希…
對於超大文件難道沒有支援分块計算，读一块算一块, 之前算过就跳过，最后再一次性生成完整hash
例如以下图示, 3种哈希也可以直接跳过"空白"、“下载中”、“已完成”、“已停用”, 只要计算 “未校验” 分块即可…
還是說, 這張圖只針對 BT分區塊有效? 其他像是 “长效” 跟 “电驴”, 躲在背景每次啟動都要乖乖來個整份檢查…@@"
是的，这张图只对BT分块有效。 “长效” 、“电驴”的分块划分方式都与BT不同，无法从BT分块转化得到。如果是彗星制作的种子文件，默认是3种哈希都算出来保存进去的。
學習了, 多謝說明!
不客气！@@
那可以多线程并发同时校验加快速度不？校验实在太慢了
Resilio Sync本来不需要挂代理，因为商业化把DHT关了。让人们开会员，所以才无法使用。
长效下着下着突然没了，，对方是1.37版本，要停止任务重新开始，才可以重新连上他的长效
就是这样，下着下着上面的长效突然没了，，看IP是同一个人，BT连接没有断，就长效消失了
感觉可能是什么网络原因导致长效突然中断了，，不过BT任务却没有断一直能持续，连接时间也没有归0，估计是重试问题了
还有，，，话说反吸血ban时间是864000，10天时间，是写错了多加了一个0，还是故意写了这么长，一般来说1天足够了吧，毕竟现在的检测机制可能会误判(主要是断流问题引起，很多peer进入后，一直处于0KB状态，，然后一段时间就被反吸血判定黄脸干掉了，之前帖子说过，最好优先解决下断流的问题吧)
https://www.cometbbs.com/uploads/default/original/2X/a/a3296909fceb68305ee02109db649dbe7733032b.gif
