Original images sometimes only return H@H url and cannot loaded from regular image servers

[a84r7a3rga76fg]

New site update broke the script

[ccloli]

I've checked a gallery just now, and I've already disabled Source Nexus, seems it's not affected.

I also checked the source code when I noticed the update yesterday, and I'm sure the new update won't break the script, since the script detects the download link by the link target url instead of the link text.

Since the new update only affects the calculation of estimated cost, so I don't make an update for now. If you're having an issue for now, please check if you can download the original images directly, or post the log from the console by pressing F12 -> Console when the script is running.

[ccloli]

- H@H High-Capacity Ranges are now live. This change lets us efficiently take advantage of surplus H@H capacity for original images with some limitations.

Specifically, the system will now use H@H for original images smaller than 10 MiB in galleries that were posted in the last year, assuming that you haven't changed the H@H setting under "Image Load Settings" to "Default port clients only" or "No". Otherwise, it will still use the regular image servers.

This change applies for regular browsing when "Prefer original images" is selected and the file would normally be resampled at 2400x, when using the "Download Original" button, and when using the H@H Downloader.

A possible reason coule be the original image may delivered from H@H, but your network cannot connect to the node. However if that's the case, there's no way to fix it since the original URL doesn't have something like "reload if image fails" link on page viewing, which will force loaded from regular servers.

A possible workaround is to set "Image Load Settings" to "Default port clients only" as the update log said, but this may costs more (though from my test the cost is the same as normal, not sure if it's a bug or I made it wrong, that's another reason why I don't make an update).

- When the "Default port clients only" setting is used, the cost for using the "Download original" button is increased.

[a84r7a3rga76fg]

Yes, it's H@H failing to serve the image properly. It sucks that the fallback URL is gone. The only way to get H@H to serve failed images is changing the IP address which is really inconvenient. Changing image load settings led to nowhere for me.

Could someone who doesn't mind getting banned ask on the forum for the fallback URL to be added back?

[ccloli]

The problem is not limited to the script, but also for common users, since there's no way to reload a url that can be loaded from source server. Not sure if append a 'nl' param would fix the issue. Consider how the original image button works, I don't see there's a convenient way for EH itself to address this case.

But I remembered the script may cache the original download url, because the url won't change, but I'm not sure if I cached the redirect url, too. If that's the case, then the script will always retry that failed image link. Would review it later today.

[ccloli]

By testing around, I can say setting to "Default port clients only" sometimes works, but it's buggy, not all the images are available.

I checked an image just now, if I set "Image Load Settings" to default "Yes", it returns an url like this: https://ucccowt.juflztpfhkbq.hath.network:7777/h/**********e1a061962aef5fd26078**********-*******-****-****-png/keystamp=1698672900-**********;fileindex=*********;xres=org/*********_p0.png The url path is started with /h/, the image is delivered through H@H.

But if I set it to "Default port clients only", the link now redirects to: https://jihcohulqbwpetewyuia.hath.network/om/*********/**********e1a061962aef5fd26078**********-*******-****-****-png/x/0/*******************/*********_p0.png The url path is started with /om/, the image is delivered from regular image server.

At least for this case, the setting is worked. But there's another case, no matter what I set, it only returns H@H url: https://obfjeyj.iwwizxogeqks.hath.network/h/**********43bfaa76a940217d71d4**********-*******-****-****-jpg/keystamp=1698673200-**********;fileindex=*********;xres=org/gelbooru_*******.jpg

[a84r7a3rga76fg]

jihcohulqbwpetewyuia.hath.network is the regular image server? I remember it as a regular exhentai URL with "nl" somewhere after it.

[ccloli]

jihcohulqbwpetewyuia.hath.network is the regular image server? I remember it as a regular exhentai URL with "nl" somewhere after it.

Yep, the regular image server serves both original images and resample images. You can see ascreenshot I uploaded before (ignore the remark and highlights), in old behavior, when requesting the original image link, it'll redirect to a link that the url path is started with /om/

[a84r7a3rga76fg]

Can you toggle "Default port clients only" if "Any client" fails to load the original image and vice versa from the browser script?

[ccloli]

Can you toggle "Default port clients only" if "Any client" fails to load the original image and vice versa from the browser script?

That would be too heavy for the script itself, and will affect all the other requests. Besides, the setting is buggy (towards to what it said in update log, but I think it's reasonable, since for this case the H@H is hosted at default port as it says in the setting), you can't say it'll return a regular server url at 100%. So I'd say no.

[ccloli]

v1.35 is released, luckilly you can append nl to original image url to let it loaded from regular server (even works for the new url format).

[Doofy420]

I've had some weird things going on as well, lots of images failing to load, and the downloader suddenly started including resized images in the zip files even though I had 'force download resized image' unchecked. Not really sure how to replicate this.

[ccloli]

@Doofy420 See #259 instead, this issue is for tracking original image url may returns H@H url only.

BTW please update to 1.35 to see if it helps.

[a84r7a3rga76fg]

Where do the numbers 37972-471877 after ?nl= come from in that screenshot?

[ccloli]

Where do the numbers 37972-471877 after ?nl= come from in that screenshot?

Reload broken image