[X] My Assistant

1.6.2 - 2023-09-14

1.6.2 is a recommended but not currently required upgrade. It may become a required upgrade in the future. Clients running 1.6.2 and newer get a 1.5x bonus to the score used for range priority promotions.

- Fixed an issue on some setups where, when running a test against other clients, two competing threads could reach a lock in an unexpected order, which would make the client report a failure before it actually ran the test.

- Fixed an issue where, if the cache was moved without preserving file modification dates and the cache is full, the cache pruner could get stuck in a loop of not finding any files to prune.

- In very rare cases, when loading persistent cache data on startup, the internal Java object deserializer could get stuck in an infinite loop if the files had been corrupted by some software or hardware issue, which required manually deleting them. We now automatically delete those files on the next startup if this happens.

- Added a way for the server to tell a client to shut down in case of persistent network configuration issues.

- Added some MIME types for possible future use.


1.6.1 - 2020-08-12

1.6.1 is not a required update, but adds some reliability improvements and checks to ensure correct operation.

- A sanity check for certificate expiry has been added. If a client does not successfully refresh the certificate for whatever reason, it will now shut down gracefully 24 hours before the certificate actually expires instead of failing silently.

- If the system time is off by more than 24 hours, a warning advising you to correct it will now be printed regularly. Failure to do so might make the certificate check trigger prematurely or fail to trigger at all.

- During proxy requests, when a file is requested but not found in cache, the backend will now provide an alternative source link in addition to the primary one. If the client is unable to connect to the primary source, it will automatically fall back to the secondary one.

- H@H now makes a best-effort attempt to include filesystem overhead for slack space in its cache size calculations. By default this calculation assumes a filesystem block size of 4kB which is by far the most common, adding an estimated overhead of 2 GB per 1 million files - roughly 0.5% for your average H@H cache.

Note that if your cache was at ~100%, this means it will be slighly over and prune this amount from the cache at the next startup. If you already left some extra space, you can increase the H@H cache by this amount BEFORE starting up to compensate. If you abort startup after seeing the pruning message, it will have to rescan the cache at next startup.

This does not reduce the amount of static ranges you can store at a given setting; it just adds 2kB (or blocksize/2) average overhead per file for the internal resource tracking.

You can specify a different blocksize with --filesystem-blocksize=xxx or turn this off by using --filesystem-blocksize=0


1.6.0 - 2020-01-02

1.6.0 is considered a stable release, and is a required update for clients running versions prior to 1.5.4. This release only has minor changes compared to 1.5.4, which remains a supported version and will not require an upgrade.

Compared to 1.4.2, this incorporates all changes in the 1.5 experimental branch. You can find those release notes here.

- When refreshing HTTPS certs, the client will now wait longer (up to five minutes) before it attempts starting the server back up if the listening thread takes unexpectedly long to terminate.

- When handling file requests, cache misses did not count towards the "total files sent" stat. (This only affected the readout in the GUI, server-side stats are not calculated by the clients.)


To update an existing client: shut it down, download Hentai@Home 1.6.2, 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 OpenJDK 8 or newer.

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.

Nice to see this project is still going, and going strong!

Do we need a minimum version of Java or something? I got this when updating my first client.

$ java -jar HentaiAtHome.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: hath/base/HentaiAtHomeClient : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:443)
at java.net.URLClassLoader.access$100(URLClassLoader.java:65)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.net.URLClassLoader$1.run(URLClassLoader.java:349)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:348)
at java.lang.ClassLoader.loadClass(ClassLoader.java:430)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:323)
at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
$ java -version
java version "1.7.0_201"
OpenJDK Runtime Environment (IcedTea 2.6.17) (7u211-2.6.17-1~deb8u1)
OpenJDK 64-Bit Server VM (build 24.201-b00, mixed mode)
$

Do we need a minimum version of Java or something? I got this when updating my first client.

You're running Java 7, make sure to update to 8 since previous versions are not supported.

What do I need to run Hentai@Home?

- [adoptopenjdk.net] OpenJDK, version 8 or newer. This is also available directly in most Linux distro repositories.

This post has been edited by nasu_sensei: Jan 2 2020, 23:47

My bad, did not see that detail. I put all the blame on the ninja edit. (IMG:[invalid] style_emoticons/default/ph34r.gif)

Is anyone else experiencing their trust and quality dropping after the update?

thanks for the hard work like always

Is anyone else experiencing their trust and quality dropping after the update?

It's normal to see a little drop, affected by your downtime. It shouldn't be constantly dropping.

I am currently running h@h 1.6 on raspberry pi 4, oracle jdk 8, bbr enabled. I see a significant max speed drop from 80000kbps to 25000kbps. Before the update i run the client on port 80 and now is 443, is that normal and will not affect the performance of my client?

Is anyone else experiencing their trust and quality dropping after the update?

If your client is updated from 1.4 and hosted on a pppoe connection with a router, take a look at "The SSL handshake times out" part on the Wiki page.

I am currently running h@h 1.6 on raspberry pi 4, oracle jdk 8, bbr enabled. I see a significant max speed drop from 80000kbps to 25000kbps. Before the update i run the client on port 80 and now is 443, is that normal and will not affect the performance of my client?

Newer H@H client uses TLS encryption, and AFAIK raspberry pi doesn't have crypto accleration, which means it's normal that your client serves less bandwidth.

Newer H@H client uses TLS encryption, and AFAIK raspberry pi doesn't have crypto accleration, which means it's normal that your client serves less bandwidth.

Dat encryption uses 80% CPU, crying. Is there any more powerful Single board computer that can run h@h?

Dat encryption uses 80% CPU, crying. Is there any more powerful Single board computer that can run h@h?

Any board with modern x86 cpus will do, although it cost more than ARM boards. I can't say about arm boards since I don't know much about them.

Is it possible and/or supported to use nginx or anything else for reverse proxying requests to H@H daemon? I already run a few sites with HTTPS on a server I run my H@H client on, so port 443 is occupied, and I want to get my client working on that port, too.

Is it possible and/or supported to use nginx or anything else for reverse proxying requests to H@H daemon? I already run a few sites with HTTPS on a server I run my H@H client on, so port 443 is occupied, and I want to get my client working on that port, too.

It's not supported but there is an option to enable it (--disable-ip-origin-check) and it has been done; see this post.

Dat encryption uses 80% CPU, crying. Is there any more powerful Single board computer that can run h@h?

Highest CPU usage I have ever seen on my RPi4 was around 30% but I only run 20k on my maximum burst speed.

You can try to use openJDK instead of oracle to see if that helps.

I didn't expect the H@H to be updated.

Other than HTTPS security stuff, I thought everything is fine.

Anyway, it might be good signal showing that admins care about the system to improve.

Just updated today, and have been running for about 12 hours. So far there hasn't been any significant performance degradations, even on the higher ports (>30000).

It's good to see a robust solution.

As a solution to Drawer L's reverse proxy woes, it may be possible to set the X-Forwarded-For/X-Real-IP header. This would, however, require client implementation and I'm not sure if that would be of a high priority.

Is it possible to support IPv6 in the future?
（My English was bad，translate with google）