[X] My Assistant

H@H will shut down cleanly on a SIGHUP or TERM, so as long as the service manager can be made to wait for H@H to shut down fully, there shouldn't be any issues. Though if it doesn't, you will have to wait for a full cache scan on the next startup, which can take a long time with large caches and/or HDD storage.

So, it's less of an issue of it being impossible, and more that doing it manually is perhaps easier depending on how knowledgeable the user is. That makes sense; thanks.

5xxx range requires 2hours to scan. OOF

Is it normal that switching to 1.6 will have a very high CPU load? I just switch to a 1.6 docker container on my NAS and upgrade to a bigger SSD for cache. Now it is running with 99% CPU usage and only 2000~3000 quality. Would I misconfigure anything?

Is it normal that switching to 1.6 will have a very high CPU load? I just switch to a 1.6 docker container on my NAS and upgrade to a bigger SSD for cache. Now it is running with 99% CPU usage and only 2000~3000 quality. Would I misconfigure anything?

TLS encryption is somewhat CPU-intensive, so if it becomes CPU-starved you may need to reduce the speed to compensate.

thank you (IMG:[invalid] style_emoticons/default/biggrin.gif)

After restart my NAS and reset everything, now it is running normally at 10000 quality and only a few percentages for >48 hours. Maybe I had misseted something when I switched to 1.6 container.

I have a interesting problem, actually I can't access my own external ip because of the router setting. However, the "Hentai@Home Local Network Host" setting is not working now. Then every album I have 1-2 image take so long to load because it assigned to my own H@H client.

This post has been edited by caxerx: Jan 16 2020, 02:31

I have a interesting problem, actually I can't access my own external ip because of the router setting. However, the "Hentai@Home Local Network Host" setting is not working now. Then every album I have 1-2 image take so long to load because it assigned to my own H@H client.

The old "Local Network Host" override wasn't usable anymore since the IP wouldn't match the hostname of the certificate. That said, I just realized it's actually fairly easy to make it work on the 1.5 system so I might re-add that functionality.

You *could* add an entry to your hosts file like

<hath_local_network_ip> <your_client.subdomain>.hath.network

but since the hosts file doesn't support wildcards, you would have to update it every time it changes every 12 hours or so. Also, there's no trivial way to get the first half of the subdomain for your client, so it's kind of awkward. On the off chance that you run your own resolving DNS server, it would be fairly workable however, with a wildcard.

The old "Local Network Host" override wasn't usable anymore since the IP wouldn't match the hostname of the certificate. That said, I just realized it's actually fairly easy to make it work on the 1.5 system so I might re-add that functionality.

You *could* add an entry to your hosts file like

<hath_local_network_ip> <your_client.subdomain>.hath.network

but since the hosts file doesn't support wildcards, you would have to update it every time it changes every 12 hours or so. Also, there's no trivial way to get the first half of the subdomain for your client, so it's kind of awkward. On the off chance that you run your own resolving DNS server, it would be fairly workable however, with a wildcard.

I think I will setup a proxy server to route my traffic and make my client run on port 443

Edit1:
Just found that the second half of subdomain is same on both my client, seems that it is hard to make my both client running on port 443

This post has been edited by caxerx: Jan 16 2020, 14:08

Just found that the second half of subdomain is same on both my client, seems that it is hard to make my both client running on port 443

You can't run two clients on the same IP anyway.

You can't run two clients on the same IP anyway.

It's different ip. But on same machine. I run it on my server that have 2 network interface.

-NVM, I'll try something in the near future, to see if it's the source of the issue-

This post has been edited by decondelite: Jan 18 2020, 10:06

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

大佬看到你给出的ssl失败给的解决办法我试了一下结果不成功，想请你帮我看看有什么问题，
2020-01-27T02:17:06Z [info] Starting up the internal HTTP Server...
2020-01-27T02:17:07Z [info] Internal HTTP Server was successfully started, and is listening on port 10000
2020-01-27T02:17:07Z [info] Notifying the server that we have finished starting up the client...
2020-01-27T02:17:14Z [WARN] Startup Failure: FAIL_CONNECT_TEST:SSL connect error
2020-01-27T02:17:14Z [info]
2020-01-27T02:17:14Z [info] ************************************************************************************************************************************
2020-01-27T02:17:14Z [info] The client has failed the external connection test.
2020-01-27T02:17:14Z [info] The server failed to verify that this client is online and available from the Internet.
2020-01-27T02:17:14Z [info] If you are behind a firewall, please check that port 10000 is forwarded to this computer.

大佬看到你给出的ssl失败给的解决办法我试了一下结果不成功，想请你帮我看看有什么问题，
2020-01-27T02:17:06Z [info] Starting up the internal HTTP Server...
2020-01-27T02:17:07Z [info] Internal HTTP Server was successfully started, and is listening on port 10000
2020-01-27T02:17:07Z [info] Notifying the server that we have finished starting up the client...
2020-01-27T02:17:14Z [WARN] Startup Failure: FAIL_CONNECT_TEST:SSL connect error
2020-01-27T02:17:14Z [info]
2020-01-27T02:17:14Z [info] ************************************************************************************************************************************
2020-01-27T02:17:14Z [info] The client has failed the external connection test.
2020-01-27T02:17:14Z [info] The server failed to verify that this client is online and available from the Internet.
2020-01-27T02:17:14Z [info] If you are behind a firewall, please check that port 10000 is forwarded to this computer.

SSL handshake timeout is longer than 7 seconds. The SSL issues you quote is unrelated. At face value, you just don't have a forwarded path through the router.

I just installed a client in docker and everything is working but once the quality reached 5k it went back in the 4k, I'm not sure what went wrong. There is not warning or error in log. Hitrate remain at 0.0 and trust 1000.

network is 300/300, installed on a ssd running debian 40gb reserved space, server was pretty much idle so there was plenty of ressource.

edit : nvm "Sudden and large drops are normal for newer clients; waiting for a few weeks will generally give a stable baseline", And i think It might need more disk space?

This post has been edited by jsrfuture: Jan 29 2020, 09:13

CODE

2020-01-29T20:06:47Z Logging started
2020-01-29T20:06:52Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-01-29T20:06:52Z [WARN] Retrying.. (2 tries left)
2020-01-29T20:06:57Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-01-29T20:06:57Z [WARN] Retrying.. (1 tries left)
2020-01-29T20:07:02Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-01-29T20:07:02Z [WARN] Retrying.. (0 tries left)
2020-01-29T20:07:02Z [WARN] Exhaused retries or aborted getting rpcdothentaiathomedotnet/15/rpc?clientbuild=151&act=server_stat
2020-01-29T20:07:02Z [ERROR] {hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:355)} Critical Error: Failed to get initial stat from server.

I started getting this issue recently, after upgrading to 1.6, but i think 1.6 was working for a few days. Any advice on how to fix this? Thx

I'm also getting the exact same issue, H@H was working great until 1.6 then it just completely stopped working after I upgraded it to 1.6 from 1.5.4 that I was using and I've been unable to get it connected for days. Even going back to 1.5.4 throws out the same error so something is fucked.

error I'm getting:

2020-02-02T18:21:37Z Logging started
2020-02-02T18:21:43Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-02-02T18:21:43Z [WARN] Retrying.. (2 tries left)
2020-02-02T18:21:48Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-02-02T18:21:48Z [WARN] Retrying.. (1 tries left)
2020-02-02T18:21:53Z [WARN] java.net.SocketTimeoutException: connect timed out
2020-02-02T18:21:53Z [WARN] Retrying.. (0 tries left)
2020-02-02T18:21:53Z [ERROR] {hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:355)} Critical Error: Failed to get initial stat from server.

I started getting this issue recently, after upgrading to 1.6, but i think 1.6 was working for a few days. Any advice on how to fix this? Thx

I'm also getting the exact same issue, H@H was working great until 1.6 then it just completely stopped working after I upgraded it to 1.6 from 1.5.4 that I was using and I've been unable to get it connected for days. Even going back to 1.5.4 throws out the same error so something is fucked.

Sockets don't remember what version you used to run. Most likely your ISP is fucked or fucking with you, seeing as you both use the same one.

Sockets don't remember what version you used to run. Most likely your ISP is fucked or fucking with you, seeing as you both use the same one.

So it's a comcast issue? Great that's never getting fixed I guess.