vibe别提，这东西比你想象的体系庞大的多。没深入前我也是这么想的，不就是metadata采集然后正则匹配各种文件名嘛。
我当前已经用komf尝试了，这玩意不光配置麻烦，还真的不好用。写入xml的效率极低，出错。
我也打算从epub元入手，直接vibe了calibre cli的方式写入。但这只限于epub，并且是那种原版自购的。img-zip这种别想了。index都没。所以得解决komga这类书库管理中的metadata自动化导入匹配的问题。
先玩了下kavita，bug更多，没功夫浪费时间。直接走komga搞。我不在乎内存占用。komga虽然对轻小说不友好，但有opds就行，甚至我根本不需要komga做壳子，有个comicopds就行。
但同样，刮削是个大问题。这里的水深还涉及到了网盘挂载以及302回原的问题。一方面影响刮削速度，一方面影响阅读速度。综合，我实在忍不了在emby可以秒播bd的体验下，等上4-5s才能打开一本漫画的现实。
刮削太慢了。在线阅读？放弃自建？显然不可能，因为在线的质量太差了。有些还有水印。甚至大部分都是压缩图，质量差的，对体验要求高的我根本受不了。
兜兜转转，还得刮削这块得解决。刮削的难度不是匹配，而是没有一个好的解决方案能batch。
komf是我见过涵盖刮削参数最多的，也是我见过最垃圾的一个应用。bug多，失败多。jre还不能调试。远古时代的产物。
我甚至有点想放弃komga，直接vibe一个采集库的想法了。奈何很多轮子得造，比如opds，比如epub.js的二开，比如，比如，比如。
1 个帖子 - 1 位参与者
来源: LinuxDo 最新话题查看原文