[X] My Assistant

Saw this in H@H log recently:

2020-05-13T05:08:27Z [WARN] CacheHandler: Encountered exception java.nio.file.FileAlreadyExistsException: E:\Hath_log\proxyfile_13974196519642105571 -> cache\6a\00\6a00a6ceefa27eeb5e59becf802199a5ce75459e-182104-1280-914-jpg when moving file E:\Hath_log\proxyfile_13974196519642105571

"File already exist" exception appearance is the kind of thing that should be easy to fix, and preventing it from happening should provide a little better performance, and take out several lines from the log (there's an entire (and useless in this case) exception hierarchy above the quoted message)

Saw this in H@H log recently:"File already exist" exception appearance is the kind of thing that should be easy to fix, and preventing it from happening should provide a little better performance, and take out several lines from the log (there's an entire (and useless in this case) exception hierarchy above the quoted message)

This happens if different people request the same non-cached file at almost the same time, and should not cause any issues. You can't really prevent this type of race condition from happening every once in a while unless you explicitly synchronize on a lock, which would hurt performance every time it doesn't happen, which is almost always.

Having weird issues with some of my H@H clients where it fails to get the image from the source server and gives timeout errors severely dropping my quality. Yet, I can immediately grab the ondemand image just fine with lynx from the same exact server without issue.

I can't fathom what the issue would be unless it was a problem with the H@H client itself.

Edit:
Jun 11 00:19:44 localhost java[19473]: 2020-06-11T04:19:44Z [WARN] Request host did not send Content-Length, aborting transfer. (sun.net.www.protocol.http.HttpURLConnection

I was able to grab the url in the error message from the same server this error was on immediately after seeing it with lynx though.

This post has been edited by yeller: Jun 11 2020, 07:01

Jun 11 00:19:44 localhost java[19473]: 2020-06-11T04:19:44Z [WARN] Request host did not send Content-Length, aborting transfer. (sun.net.www.protocol.http.HttpURLConnection

I was able to grab the url in the error message from the same server this error was on immediately after seeing it with lynx though.

Could be a transient network issue, or possibly be transparently reverse-proxied in some way that drops the content-length header. I don't know about Lynx, but wget allows you to dump the headers with --server-response so you can try using that to check the latter.

Could be a transient network issue, or possibly be transparently reverse-proxied in some way that drops the content-length header. I don't know about Lynx, but wget allows you to dump the headers with --server-response so you can try using that to check the latter.

I think I found the particular server I'm getting packet loss to, I'm not getting it to any of the others I've pinged for hours on end.

Although it's hard to tell for sure because ICMP ping is blocked to that particular server, but if I use hping to do "tcp pings" to port 80 it loses like 30%. Then again I don't know if this is normal and some sort of anti DoS measure.

It's also the server I'm seeing the timeouts to.

Edit: Seems this problem got magically fixed after moaning about it to the right people.

This post has been edited by yeller: Jun 13 2020, 10:02

Was I supposed to get a client ID or something? I filled out the application and got "accepted" but I don't know what to put in that prompt when it first opens up.
EDIT: I was dumb. Nevermind.

This post has been edited by LordH3lix: Jun 24 2020, 12:37

Nice.

I have a feature request for 1.6.1. Make the client just exit if it can't find 10+ files in cache suddenly.

Bad things happen if network storage disappears.

Seems to go in line with the auto exiting of the client if there is no disk space.

Edit: Never mind. I'm dumb. It's the improper shutdown that's really the problem.

This post has been edited by yeller: Jul 3 2020, 06:51

It's good to see a robust solution.

2020-07-09T10:05:03Z [info] {******/**.**.***.**} Code=301 Bytes=0 GET /favicon.ico HTTP/1.1
2020-07-09T10:05:03Z [info] {******/**.**.***.**} Code=301 Bytes=0 Finished processing request in 0,00 seconds

(I hid with * things that may identify an user, not the important part anyway)
I find that a bit disturbing.
I understand it may be meaningful within the log_out file, but I wish it wasn't displayed in the log of the GUI (that already hide lots of things of the log file).
Just my thought though.Not a big matter.

This post has been edited by uareader: Jul 9 2020, 22:35

improved release sounds great, updating

thanks for the hard work like always

1.6.1 was released. This 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


To update an existing client: shut it down, download Hentai@Home 1.6.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 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.

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

Nice. I have already installed it and will test it if everything runs stable.

thanks for the hard work like always

- 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.

You have no idea how much of a savior that will be for us. I'll really update my clients ASAP.

Wish I could get more performance out of my node. I have 10gbps + hardware raid array + datacenter premium bandwidth (IMG:[invalid] style_emoticons/default/sad.gif)

- 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.

Thank you for implementing the filesystem overhead calculations! After pruning my server has freed up more than 2 GiB of space - working exactly as intended!

Here's a link to the relevant discussion, in case anyone is wondering what this new feature is about.

This post has been edited by cklodar: Aug 16 2020, 01:20

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

Probably yes

Thanks for update (IMG:[invalid] style_emoticons/default/biggrin.gif)!!