Da'Inihlus
Da'Inihlus
和之前的那个pr差不多，主要是修了些问题。 ## 1，新的文件名控制。 在exhentai浏览画廊单独一页时，比较大的png都会变成jpg，比较小的png会保持png。具体是否会压缩的分界点和图片源的链接带宽有关系。这也即是说原本是png的画廊下载的文件实际是png还是jpg完全无法简单预计。 除此之外，gif文件也会被下载成jpg。 这里采用了另一种办法：在ehentai的画廊页面里，每一页预览的title里面包含了原本的文件名。单独一页中的顶部和底部显示的文件名是压缩转码后的文件名。我使用这些文件名取代了原本的rename_map机制。 具体工作方式如下： * 在TASK_STATE_SCAN_PAGE阶段，从画廊获取原文件名，存入fid_2_original_file_name_map 此时如果出现重名，添加"_1"到文件名末尾，仍然重名则使用"_2"，以此类推 * 在TASK_STATE_SCAN_IMG阶段，从单独页上获取实际文件名（主要是扩展名），存入fid_2_file_name_map * 在TASK_STATE_SCAN_IMG阶段，从单独页上获取文件体积信息，存入fid_2_file_size_map * 保存文件时直接使用获取到的文件名，无需最后再改名 ## 2，zip描述信息改动 把h.json里面的一些信息搬到了zip里，包括gjname、gnname、tags、total、title、rename_ori、download_ori、url、fid_fname_map。最后这个task.fid_fname_map是上述的文件名控制用到的，用于描述第几页文件名为何。 这使得zip文件能够自我描述比较完整的画廊信息，在TASK_STATE_SCAN_PAGE阶段中，这些信息也用于检测zip文件是否需要重新下载等等。 这也使得载入其他方式转移来的文件成为可能，让xehentai有可能成为一个下载画廊管理软件。 ## 3，scan_downloaded和prescan_downloaded 由于上述文件名控制原理，到TASK_STATE_SCAN_IMG的时候才能知道实际的文件名。 prescan_downloaded负责扫描zip文件的描述信息。通过以下四个方面决定如何操作该zip： * fid_fname_map是否存在，其长度是否等于total。不存在或者小于total都表示这个文件不太像这个软件下载的，由于可能是早前版本下载的，所以先解压出来重新下。 * download_ori不匹配，解压出来重新下。但如果zip文件download_ori为True，而task的download_ori为False，那就不管。 *...
### 在提问之前... - [X] 我已经搜索了现有的 issues - [X] 我在提问题之前至少花费了 5 分钟来思考和准备 - [X] 我已经阅读了 Wiki 中的 常见问题(FAQ) - [X] 我正在使用最新版的 Alas ### 描述你的问题 看过了#1533，我这里会提供更多的信息 问题的主要情况如下： * 将Alas连接到模拟器，在一段时间的连续运行后，Alas可能会卡在“重启设置”的状态。 更进一步的折腾发现了如下情况： * 在这个卡住的状态里，模拟器并没有卡住，仍然可以通过鼠标点击正常使用。...
由于众所周知的不可抗力因素，项目以后的发布将包括原始dll和json。不再发布cpk。 此外，可以使用[这个项目](https://github.com/iTXTech/mirai-native)来实现机器人。 本人出差结束后会将安装部署部分更改为对应上述的项目的方式。
既然现在停止维护，可以将开发工作交给社区。