CreeperAWA

> > > 大佬您的 test-nine 和 MihoyoBBSTools 也是 Docker 运行吗？您看能不能给我个镜像测试一下？ > > > > > > 你的test-nine 是否使用host网络模式？ 这是我构建的镜像[captcha-tools](https://hub.docker.com/r/kafuneri/captcha-tools) 使用`docker-compose.yaml`： > > version: '3' > > services: > > captcha-tools:...

> > 大佬您的 test-nine 和 MihoyoBBSTools 也是 Docker 运行吗？您看能不能给我个镜像测试一下？ > > 你的test-nine 是否使用host网络模式？ 这是我构建的镜像[captcha-tools](https://hub.docker.com/r/kafuneri/captcha-tools) 使用`docker-compose.yaml`： > > version: '3' > services: > captcha-tools: > image: kafuneri/captcha-tools:latest # arm64设备使用captcha-tools:arm64 > container_name:...

> > 大佬您的 test-nine 和 MihoyoBBSTools 也是 Docker 运行吗？您看能不能给我个镜像测试一下？ > > 你的test-nine 是否使用host网络模式？ 这是我构建的镜像[captcha-tools](https://hub.docker.com/r/kafuneri/captcha-tools) 使用`docker-compose.yaml`： > > version: '3' > services: > captcha-tools: > image: kafuneri/captcha-tools:latest # arm64设备使用captcha-tools:arm64 > container_name:...

感谢大佬，我解决了 test-nine 的 main.py 判断等待时间的地方加一个判断所用时间，超过或等于4秒不等待就好了 ```python point_list = [f"{col}_{row}" for row, col in result_list] elapsed_time = time.time() - t wait_time = max(0, 4.0 - elapsed_time) # 确保等待时间不为负数 if wait_time >...

我的就是SSD（截图非解压时的截图）   这个问题是更新启动器后才出现的

> 同时进行的解压任务只可能存在一个，这样会保持一个较低的硬盘占用，如果仍能达到100%的话，建议你把游戏安装在固态硬盘中。 我还是建议先写入内存再写入硬盘

> 有不少硬碟在快取用完時 寫入會降速（這點可以透過傳輸大型檔案復現） 而讀取還是同樣的速度 此時解壓縮後的資料來不及寫入硬碟 往內存堆積 工作管理員估計會看到內存高佔用的情形 zh_TW 然而，Starward直接暫停了解壓（速度為0），並沒有寫入記憶體（工作管理員可看出）。 市面上大多數的壓縮軟體在遇到這種情況下都會選擇寫入記憶體的（以前Starward也會這樣吧），所以我認為這個解壓邏輯並不正確。 我建議直接在軟件打包時包含7-Zip，解壓時調用7-Zip； 或者使用用戶系統中的7-Zip。 zh_CN 然而，Starward直接暂停了解压（速度为0），并没有写入内存（任务管理器可看出）。 市面上大多数的压缩软件在遇到这种情况下都会选择写入内存的（以前Starward也会这样吧），所以我认为这个解压逻辑并不正确。 我建议直接在软件打包时包含7-Zip，解压时调用7-Zip；或者使用用户系统中的7-Zip。

> 实际这些方法不如搞fp，拿合法设备的fp可以降低出现验证码的情况 我加了以后是不是不能PR

> fp可以Pr，但是要用户自行填写，fp使用的让过多出现异常了照样也会出现验证码 那我明天整理一下就PR

> 指的应该是触发检测的阈值吧 我猜测可能是，但我认为这样表达不严谨且容易引起误会