[X] My Assistant

- Malformed requests such as those made by Firefox 51 are now detected and terminated early, rather than having the connection sit around and wait for the normal timeout.

- To save some CPU time, the GUI will no longer call for a repaint every time the stat readouts change. Twice per second should be sufficent.

- Updated some URL readouts to use the new HTTPS URLs.

This will become a required update very soon. Note that because of the issues caused by the non-conformant behavior of Firefox 51, we will also be retiring the 1.2 branch earlier than planned. If you are still running on the 1.2 branch, you will want to update to 1.4.1 ASAP.


To update an existing client: shut it down, download Hentai@Home 1.4.1, extract the archive, copy the jar files over the existing ones, then restart the client.

The full source code for H@H is available and licensed under the GNU General Public License v3, and can be downloaded here. Building it from source only requires the free Java SE 7 JDK.

For information on how to join Hentai@Home, check out The Hentai@Home Project FAQ.

Other download options can be found at the usual place.

Recent release notes: 1.4.0 - 1.3 Experimental Branch

My client has been updated. Everything seems to work well.
Thank you for the quick update for Firefox users. I hope Mozilla will fix their issue regardless in due time.

Thank you for the quick update for Firefox users. I hope Mozilla will fix their issue regardless in due time.

They have [bugzilla.mozilla.org] confirmed the bug, currently classified as a major severity regression. But it's hard to say when it would be patched, and having a fast-fail workaround deployed on our end is helpful anyway, in case similar issues crop up in the future.

Updating as of now from 1.2.6 to 1.4.1. Lets hope it goes fine as the version gap is quite big.

Updating as of now from 1.2.6 to 1.4.1. Lets hope it goes fine as the version gap is quite big.

It'll take a while for the first startup, but there's no difference with going from 1.2.6 to 1.3.0 or going directly to 1.4.1, the cache structure didn't change between those releases.

is this issue just for the 51 branch?

I've been using the Developer Edition for almost a year and is currently on the 52 version.

They have [bugzilla.mozilla.org] confirmed the bug, currently classified as a major severity regression.

Also marked it as a dupe so there is a bigger look into it from ckerschb here:
[bugzilla.mozilla.org] https://bugzilla.mozilla.org/show_bug.cgi?id=1328460

is this issue just for the 51 branch?

I've been using the Developer Edition for almost a year and is currently on the 52 version.

Affects 51+ and all current experimental versions, as far as I know.

Also marked it as a dupe so there is a bigger look into it from ckerschb here:
[bugzilla.mozilla.org] https://bugzilla.mozilla.org/show_bug.cgi?id=1328460

Yeah, I saw that, didn't show up in a search for some reason. Really makes them look even worse, since that bug was opened January 3rd, and they still pushed it as a broken default-on feature in 51.

They do have a system in place to make sure Firefox ships without any open regression bugs for that branch. But it looks like the dev who filed that bug didn't set the right flags for that, so it slipped through the cracks. Pretty annoying.

just found out that I needed to update the client after I restarted my PC today~
Thx for the update (IMG:[invalid] style_emoticons/default/smile.gif)

Those big red warning messages finally makes me get off my lazy asses, to restart my server and update my client from 1.2.6 to the latest version.

hi, i don't know if the new version is the problem but it worked til a few days ago now my h@h wont proxy the gallery im reading(so i use up my limit) is this because of the new client?

Wasn't there a feature to load images through one of your servers (not the local proxy)? The setting seems to have disappeared if there was.

Will it be making a return?

Wasn't there a feature to load images through one of your servers (not the local proxy)? The setting seems to have disappeared if there was.

Correct, there was one. But got dumped in favour of static ranges.

Will it be making a return?

Not really. It does not provide an advantage anymore since the majority of cache comes from static ranges.

In general the H@H proxy is not as efficient as a generic proxy (squid, ssh -D, polipo) due to the JVM overhead (it isn't much overhead but there is some). So for a server based proxy it is much better to use on of those. And you can then use it for other things, not only EH.

Jesus...
Why does a proper stop (understand: shutting down the H@H service on my linux host) does not actually stop properly? I did "/etc/init.d/hentaiathome stop", waited like a good boy for it to finish, uploaded the 3 files (from 1.4.0 to 1.4.1...), started and... -100 trust and never ending quality drop.

Been two hours I'm trying to get that thing fixed, and it still won't work properly. Now I have to verify a huge cache, and I don't even know if it'll even work.

Isn't there something wrong in the client? I don't think it's normal not to see the client as "Offline" in my client summary, when I did shut it down correctly.

This post has been edited by decondelite: Jan 30 2017, 22:26

Why does a proper stop (understand: shutting down the H@H service on my linux host) does not actually stop properly? I did "/etc/init.d/hentaiathome stop", waited like a good boy for it to finish, uploaded the 3 files (from 1.4.0 to 1.4.1...), started and... -100 trust and never ending quality drop.

We don't have any official init scripts for H@H, so most likely it didn't shut it down cleanly. Worst case, when everything is working again, the trust/quality should start climbing around 60 minutes after an unclean shutdown.

I picked up the "H@H as service" from the wiki... (IMG:[invalid] style_emoticons/default/unsure.gif)
https://ehwiki.org/wiki/Installing_H@H_on_Debian
I know it's not really official, but hey it's our God mister wiki!

Now that I rethink about it (and finally got the machine to work properly... never touching it again for years now), there could be small compatibility/rights issues with Debian 8. Or with the Java version, who knows. I already had quite a lot of trouble last month to connect through SSH and get H@H to work the first time after all.

This post has been edited by decondelite: Jan 31 2017, 01:22

Correct, there was one. But got dumped in favour of static ranges.

Not really. It does not provide an advantage anymore since the majority of cache comes from static ranges.

In general the H@H proxy is not as efficient as a generic proxy (squid, ssh -D, polipo) due to the JVM overhead (it isn't much overhead but there is some). So for a server based proxy it is much better to use on of those. And you can then use it for other things, not only EH.

I see. I set that up and works just fine. Thanks.

I picked up the "H@H as service" from the wiki... (IMG:[invalid] style_emoticons/default/unsure.gif)
https://ehwiki.org/wiki/Installing_H@H_on_Debian
I know it's not really official, but hey it's our God mister wiki!

Now that I rethink about it (and finally got the machine to work properly... never touching it again for years now), there could be small compatibility/rights issues with Debian 8. Or with the Java version, who knows. I already had quite a lot of trouble last month to connect through SSH and get H@H to work the first time after all.

Debian 8 comes with systemd, I'm not sure if initd still works, but you should create a service with systemd if you're on Debian 8.

I have notified Cyberfox of the bug and the thread from Mozilla so I am sure they will be working on fixing it soon. Cyberfox developers really are on the ball and work to fixing issues quickly when found. Awesome support and I have dumped Firefox a long time ago for Cyberfox.

Cyberfox 4 flavors.. x86 Intel, x64 Intel, x86 AMD, x64 AMD

and the support that we use to see back in the old Firefox 4 days.