xeHentai icon indicating copy to clipboard operation
xeHentai copied to clipboard

Doujinshi downloader 绅士漫画下载

Results 11 xeHentai issues
Sort by recently updated
recently updated
newest added

版本 xeHentai 2.023-cab811e(2.023) 失败: 1013 INFO - [20:57:38] 绅士 6R/0Z, 队列 0R/244D, 79.58 KB/s DEBG - [20:57:41] 绅士-down-5 已下载图片 #186 Vampire_Master_1_189.jpg INFO - [20:57:43] 绅士 6R/0Z, 队列 0R/245D, 0 B/s...

![image](https://user-images.githubusercontent.com/47025714/160243222-8ef3a6c7-8572-4839-932c-709395d5ef13.png) 没有连接上,我的win可以用,linux就不行了,py2和py3都试过

请教一个问题。 在下载数量超过400张的图集时,经常会出现下面这种情况,一旦出现这个,下载配额会被疯狂吞掉。好像是一条提示要吞掉10点的下载配额。而且它会一直重复这个错误,直到所有的配额全部消耗完为止。 请问有任何办法避免这个吗?或者是在出现这种情况后能让下载自动停止下来吗?以避免吞掉所有的配额。 DEBG - [00:18:43] 绅士-down-1 下载图片 #574 时出错: 连接有问题?, 将在稍后重试 DEBG - [00:18:44] 绅士-down-1 下载图片 #575 时出错: 下载链接不太正常, 将在稍后重试 DEBG - [00:18:44] 绅士-down-1 下载图片 #576 时出错: 下载链接不太正常, 将在稍后重试...

老哥打包个linux版本的可执行文件吧,用作服务器的话,包版本的兼容是个问题,我运行的时候就出错了。windows版本的exe文件执行就没有问题。

和之前的那个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,那就不管。 *...

主要是因為有Image Limits的關係。 但如果上個學之類的,Image Limits歸0但沒有手動用Web版按開始的話,就一直都會顯示失敗。 如果能多一個等待Image Limits下降到一個值,然後開始自動續載。 這樣就能一直掛著了。 謝謝。

enhancement

https://e-hentai.org/g/{gallery_id}/{gallery_token}/ 本子地址应该是这样的 希望能在漫画名前加上gallery_id 更好搞清楚下的是哪个版本的本子

enhancement

用其他软件发送相同请求得到相同的返回结果(recapcha验证失败) 若有解决方法求告知

https://exhentai.org/g/1283918/1ae7835b3f/# https://exhentai.org/g/1643021/6dc1d546d9/# https://exhentai.org/g/2232697/d6480df659/# 用xeHentai下載上述連結時,均會出現下列錯誤訊息 ``` DEBG - [01:51:00] 更新渠道為: 正式版 INFO - [01:51:00] xeHentai 2.023-cab811e(2.023) 已啟動 INFO - [01:51:00] RPC伺服器監聽在 localhost:8010 INFO - [01:51:00] WebUI 地址為 http://localhost:8010/ui/#host=localhost,port=8010,https=no 或者 https://xehentai.yooooo DEBG...

使用的客户端版本: > 从官网 https://dl.yooooo.us/share/xeHentai/ 下载的 xeHentai-2.0.2.3-稳定版.exe.zip,已配置更新到测试分支 发现问题的过程: > 同时使用代理来下载图片和扫描网页,代理在下载到某张图片时会卡住不动 解决问题的临时方法: > 切换另一个代理下载,或者手动到下载失败的图片页面下方点击 `Click here if the image fails loading` ,再手动保存到本地 初步推测问题产生的原因: > 从切换代理后能正常访问来看(日志显示访问的是同一图片链接),可能是某些 H@H 客户端的主人配置防火墙屏蔽了代理的 IP config.py 里有这么一行设置,预期应当会重新换源下载 ``` #...