[X] My Assistant

You can find this under settings now. There were some minor changes made to it, and the smallest row option was left out for space reasons, so let me know if there are any issues with it.

Thank you very much; very convenient for vigilante work to have this toggle back where it used to be.

This post has been edited by Glovelove.: Oct 31 2023, 18:10

Hm. Well, if anything that makes it much easier. I tried to add a header to the redirect which did nothing, but running it through a server-side URL rewrite seems to do the trick - in other words, instead of linking to fullimg.php?xyz it'll just link to fullimg/xyz/filename.jpg instead.

I'll push a fix for this with the next update.

Thank you very much for the quick turnaround. The MPV now is a real "a" link, and both of them now correctly download with an image filename whether via alt-click or right-click->save as.

...Minor nitpick: If I do a right-click Save As on that image's link, I get "014_010_011_copy.png" as expected. But if I alt-click, I get "014_010_011_copy.jpg" instead - same data but with a JPG extension. And inspecting the link shows it's "https://e-hentai.org/fullimg/xxxxxxx/014_010_011_copy.jpg". (Guess that confirms how Firefox gets the filename to use via different paths.)

I assume that the URL rewrite is using the resized filename (always JPG) instead of the original filename (JPG or PNG or etc based on file)?

...Minor nitpick: If I do a right-click Save As on that image's link, I get "014_010_011_copy.png" as expected. But if I alt-click, I get "014_010_011_copy.jpg" instead - same data but with a JPG extension. And inspecting the link shows it's "https://e-hentai.org/fullimg/xxxxxxx/014_010_011_copy.jpg". (Guess that confirms how Firefox gets the filename to use via different paths.)

I assume that the URL rewrite is using the resized filename (always JPG) instead of the original filename (JPG or PNG or etc based on file)?

Oh right, good catch. It should be using the correct extension now.

Let me know if you're still seeing anything like this after today's update.

I checked several galleries and drag & drop seems to be keeping the correct filenames now, thanks for the fix! If I notice anything strange again, I'll report it.

I'm one of those people who really liked the automatic "Save As" dialog. Especially since I have things configured to skip the dialog here, so I just click it and poof it's downloaded.

Exactly, same here, I loved the previous system precisely because of how quick it was if you had configured your browser to skip the dialog and automatically download the images. But that's okay, I guess what we have now is the second best possible option, EH for single images will be like Pixiv for me from now on and I'll get used to it in no time.

Oh right, good catch. It should be using the correct extension now.

Perfect; thanks again.

Exactly, same here, I loved the previous system precisely because of how quick it was if you had configured your browser to skip the dialog and automatically download the images. But that's okay, I guess what we have now is the second best possible option, EH for single images will be like Pixiv for me from now on and I'll get used to it in no time.

Yeah, the old one was optimal for my usages, but an alt-click is "good enough". Certainly better than the half dozen clicks it was yesterday.

After the “Chinese Dominion" was established separately, the traffic of my H@H client plummeted, and the revenue was only 1/2 to 2/3 of the original. The traffic in the morning and evening was very different. (IMG:[invalid] style_emoticons/default/sad.gif)

After the “Chinese Dominion" was established separately, the traffic of my H@H client plummeted, and the revenue was only 1/2 to 2/3 of the original.

It's been in effect for quite a while actually, like before the readouts were made publicly available. You sure it's not because of some other factors? e.g., overloads, insufficient speed, low P1s

The traffic in the morning and evening was very different. (IMG:[invalid] style_emoticons/default/sad.gif)

Pretty sure it's normal to have traffic fluctuate like that. People generally don't flap at work/school after all.

Computer: The HV link is there on the main site up at the top again. Thanks! Looks good and back to normal.


Cellphone: Once in a while I'll come to the site on my cellphone without signing in to read posts while I'm taking a dump and also try and see my banner out front. The banners now appear bigger in size than they used to and cut off on the right side. Not a huge deal but it looks weird. Anyway, I rarely if never see my banners anymore since they rotate hourly now. :/

Is it just me, or did mpv break all of a sudden? I have mine set to "Align Center, Scale Down Only". This used to fit the page 100% vertically, now only 70% of the page fits and I have to scroll down. I tried in both chrome and firefox with all my extensions off.

Edit: I think this may be the default behavior, and I had some scripts to fix it. I noticed others mentioned changing "mi0" and "mi1" with "mimg" and "mbar" which seems to do the trick.

This post has been edited by evolut1010: Nov 7 2023, 00:31

2023-10-31
- Added a toggle under My Settings to re-enable the gallery page thumbnail selector. There were also some tweaks made to this selector to make it fit better on narrow screens for galleries with many pages.

Appreciated. Also keep up the good work! (IMG:[invalid] style_emoticons/default/smile.gif)

I'll consider it if there are other regulars who found it genuinely useful.
The change was made due to UI scaling, and I'm not planning on reverting it. People can choose 1280x manually if they want it.

And how do I do that without an account?

And how do I do that without an account?

You don't.

On the topic of MPV issues... Recently it seems to be behaving more weirdly.

One seems to come down to some change that broke a userscript (disabling the custom scroll function on MPV because it's a stuttery mess on my system). Clicking an individual page used to open MPV scrolled to that page, and now it always opens scrolled to the first page... But disabling my userscript "fixes" it, so that's my problem I guess.

But the other I can reproduce with no modifications (it's just harder) so it's an actual bug I think. Sometimes, when clicking on the "Close Image Viewer" in the top right, instead of closing and returning to the gallery, it just refreshes the page. Poking around a bit, it seems to be caused by the following:
1) Clicking the close button runs "action_gallery()", which attempts to navigate to the gallery
2) Before the page can actually change, "force_reload()" fires out of nowhere, which attempts to navigate to the MPV again
3) Since the reload call happens after the gallery call, it effectively cancels/overrides it, and the end effect is the MPV is reloaded

My guess is that the galley navigation causes my browser to cancel the background MPV loads (makes sense), causing them to call their fail handlers. Sure enough, if I load the MPV then click the close button ASAP - before the first image has loaded/displayed - it reliably triggers the behavior. And finally, tweaking it so that the gallery call neuters the reload call before navigation prevents the behavior.

Not sure if something changed recently to cause this, or if it's always been there and just I never noticed... or heck, maybe Firefox recently changed how they handle interrupted background calls. Who knows.

But the other I can reproduce with no modifications (it's just harder) so it's an actual bug I think. Sometimes, when clicking on the "Close Image Viewer" in the top right, instead of closing and returning to the gallery, it just refreshes the page. Poking around a bit, it seems to be caused by the following:
...
Not sure if something changed recently to cause this, or if it's always been there and just I never noticed... or heck, maybe Firefox recently changed how they handle interrupted background calls. Who knows.

Yeah, most likely there is an image currently being loaded, and trying to navigate away from the page makes the browser cancel that load, which fails it and triggers the reload mechanism.

This behavior hasn't changed for over a decade, so either it's always been there or recent changes to the browser you are using are triggering it, but I suppose it makes sense to disable the reload mechanism as soon as you try to navigate back to the gallery.

Seems like the October update broke this userscript https://forums.e-hentai.org/index.php?showt...mp;hl=lazy+load any idea what changed?

Yeah, most likely there is an image currently being loaded, and trying to navigate away from the page makes the browser cancel that load, which fails it and triggers the reload mechanism.

This behavior hasn't changed for over a decade, so either it's always been there or recent changes to the browser you are using are triggering it, but I suppose it makes sense to disable the reload mechanism as soon as you try to navigate back to the gallery.

fwiw I’ve experienced this bug for years but assumed it was due to my weird setup. So I’m glad it’s fixed.

This post has been edited by Cipher-kun: Nov 10 2023, 16:29

fwiw I’ve experienced this bug for years but assumed it was due to my weird setup. So I’m glad it’s fixed.

It's not fixed yet, but it should be fixed the next time I push a new version of the javascript.

The change was made due to UI scaling, and I'm not planning on reverting it. People can choose 1280x manually if they want it.

You should change the description in the Settings panel though. It's very misleading at the moment.
Also, you do know, but I believe the useragent filter could be improved or made more specific. There are even many mobile apps (that don't have a "HTML viewport" to fix then) that were caught in this change.

Also, you do know, but I believe the useragent filter could be improved or made more specific. There are even many mobile apps (that don't have a "HTML viewport" to fix then) that were caught in this change.

If it sends "mobile" or "iphone" as part of the useragent string, it's literally asking for a mobile-friendly version. If it doesn't want that, it shouldn't impersonate a mobile browser.

Not to mention that apps that impersonate a mobile browser will impersonate a specific mobile browser that actually exists, so making the filter "improved or made more specific" is literally impossible.

Hello, just wanted to ask about the changes to the 'download original' button from the 10-27 update. Just like some others have mentioned, I was a frequent user of the 'download original' button to quickly save a high-res image without needing to right-click, rename the file etc., This feature was especially useful in variant galleries with only minor changes between images (such as those by mk) to just download a few of the best choices without a lot of right clicking. I've been able to get around this change on pc by using a script to bind alt+left-click to middle mouse whilst on the site, allowing a single MMB press on the 'download original' button to behave as it did before, but this isn't possible to do on mobile (unless I'm missing something).

On mobile, to save a full res version of an image, you're now required to press and hold on the 'download original' button, then press 'download link' from the context menu (and in the case where a file's default name is simple, like "1", "2", or "original_1" etc., you'll also be prompted to 'download file again', which will then add a (1), (2) suffix. as required). This significantly increases the time taken to save an image compared to the previous single tap to save option, which would also auto-add a (1), (2) numerical suffix. to files when needed.

I appreciate that if this feature has been rarely used by the rest of the sites visitors, then the current change likely doesn't bother many people, but if possible, could an option be added (maybe under settings?) to revert the 'download original' button to it's previous usage? If not then I'll look into a work around for using the site on mobile. Thanks for your continued efforts maintaining the site.