[X] My Assistant

Client 41453 cannot startup:

2023-09-29 20:34:26+7 [WARN] java.io.IOException: Server returned HTTP response code: 500 for URL: [94.100.24.68] http://94.100.24.68/15/rpc?clientbuild=160&a...
2023-09-29 20:34:26+7 [WARN] Startup Failure: FAIL_STARTUP_REPLAY;Cannot initiate startup multiple times with the same key. Restart H@H and try again.

I tried to reset client key but didn't works.

Client 41453 cannot startup:

2023-09-29 20:34:26+7 [WARN] java.io.IOException: Server returned HTTP response code: 500 for URL: [94.100.24.68] http://94.100.24.68/15/rpc?clientbuild=160&a...
2023-09-29 20:34:26+7 [WARN] Startup Failure: FAIL_STARTUP_REPLAY;Cannot initiate startup multiple times with the same key. Restart H@H and try again.

I tried to reset client key but didn't works.

Same thing here (ID 46318), happened after I updated the client, huh? Was working fine until 4 hours ago...

"Downgrading" back to 1.6.1 didn't help.

This post has been edited by SuicideTree: Sep 29 2023, 16:05

Same with 30100. Had to restart the server and hath service didn't start up with this error

Hmm, looks like it didn't take kindly to a core library update. I've fixed the issue, so clients that could not start up should be able to again now.

Hmm, looks like it didn't take kindly to a core library update. I've fixed the issue, so clients that could not start up should be able to again now.

Thanks, looks like we're back to normal.

I'm suddenly getting the following error after a restart:

2023-09-29T23:06:57Z [WARN] java.net.SocketTimeoutException: Connect timed out
2023-09-29T23:06:57Z [WARN] Retrying.. (2 tries left)
2023-09-29T23:07:02Z [WARN] java.net.SocketTimeoutException: Connect timed out
2023-09-29T23:07:02Z [WARN] Retrying.. (1 tries left)
2023-09-29T23:07:07Z [WARN] java.net.SocketTimeoutException: Connect timed out
2023-09-29T23:07:07Z [WARN] Retrying.. (0 tries left)
2023-09-29T23:07:07Z [WARN] Exhaused retries or aborted getting [rpc.hentaiathome.net] http://rpc.hentaiathome.net/15/rpc?clientb...act=server_stat
2023-09-29T23:07:07Z [ERROR] {hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:369)} Critical Error: Failed to get initial stat from server.

Indeed if I try to ping rpc.hentaiathome.net from this server I get no replies - however if I try to ping it from my current location (on a different IP), it works fine.

Edit: Well I just locked myself out of being able to remotely access the server, so I guess I'm not fixing this until I'm back from my holiday.

This post has been edited by Ver Greeneyes: Sep 30 2023, 02:58

Hitrate: 20.5 / min
Hathrate: 34.3 / day

It sure fell a lot after the recent change. I remember joking (but I could not find my post about it, must have not mentioned "h@h" thus not having keyword, or I just thought it a lot without posting) about getting hit more than once per second before.
I wonder if it will take as much time to recover, as it took time to start from zero and build up performance?

I wonder if it will take as much time to recover, as it took time to start from zero and build up performance?

Depends on your client's specs and location. If this was one of those clients in Europe with large-ish HDD and slow-ish speed, it'll go back up somewhat over time, but Europe is pretty oversaturated so it probably won't go back to where it was.

Something strange with client 44663
Network issue on Sep 27 and it was temporarily limited to 80% (from 30000 KB/s to 24000)
And it is limited to 20000 in recent 3 hours

CODE

eth0  /  daily

          day        rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     2023-09-25    66.64 GiB |    1.59 TiB |    1.66 TiB |  168.99 Mbit/s
     2023-09-26    58.35 GiB |    1.38 TiB |    1.43 TiB |  145.89 Mbit/s
     2023-09-27    69.14 GiB |    1.65 TiB |    1.72 TiB |  174.78 Mbit/s
     2023-09-28    90.58 GiB |    2.09 TiB |    2.18 TiB |  221.99 Mbit/s
     2023-09-29    90.24 GiB |    2.09 TiB |    2.18 TiB |  221.46 Mbit/s
     2023-09-30    91.96 GiB |    2.10 TiB |    2.19 TiB |  222.67 Mbit/s
     2023-10-01    92.83 GiB |    2.10 TiB |    2.19 TiB |  222.97 Mbit/s
     2023-10-02    95.58 GiB |    2.13 TiB |    2.22 TiB |  226.06 Mbit/s
     2023-10-03    94.32 GiB |    2.12 TiB |    2.22 TiB |  225.54 Mbit/s
     2023-10-04    45.75 GiB |    1.02 TiB |    1.06 TiB |  218.00 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated     92.13 GiB |    2.05 TiB |    2.14 TiB |

CODE

         hour        rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     2023-10-03
         12:00      3.96 GiB |   90.00 GiB |   93.95 GiB |  224.18 Mbit/s
         13:00      4.03 GiB |   90.53 GiB |   94.56 GiB |  225.62 Mbit/s
         14:00      4.04 GiB |   91.14 GiB |   95.18 GiB |  227.11 Mbit/s
         15:00      4.17 GiB |   93.37 GiB |   97.55 GiB |  232.76 Mbit/s
         16:00      4.23 GiB |   94.71 GiB |   98.94 GiB |  236.08 Mbit/s
         17:00      4.14 GiB |   93.37 GiB |   97.51 GiB |  232.66 Mbit/s
         18:00      3.94 GiB |   90.95 GiB |   94.89 GiB |  226.42 Mbit/s
         19:00      3.72 GiB |   89.44 GiB |   93.16 GiB |  222.28 Mbit/s
         20:00      3.58 GiB |   88.24 GiB |   91.82 GiB |  219.09 Mbit/s
         21:00      3.51 GiB |   86.93 GiB |   90.44 GiB |  215.79 Mbit/s
         22:00      3.52 GiB |   88.34 GiB |   91.87 GiB |  219.20 Mbit/s
         23:00      3.83 GiB |   90.13 GiB |   93.96 GiB |  224.19 Mbit/s
     2023-10-04
         00:00      3.95 GiB |   90.76 GiB |   94.71 GiB |  225.98 Mbit/s
         01:00      3.85 GiB |   90.39 GiB |   94.24 GiB |  224.85 Mbit/s
         02:00      3.94 GiB |   90.81 GiB |   94.75 GiB |  226.08 Mbit/s
         03:00      3.88 GiB |   90.78 GiB |   94.67 GiB |  225.89 Mbit/s
         04:00      4.05 GiB |   90.33 GiB |   94.38 GiB |  225.19 Mbit/s
         05:00      4.05 GiB |   91.33 GiB |   95.38 GiB |  227.58 Mbit/s
         06:00      3.88 GiB |   90.34 GiB |   94.22 GiB |  224.83 Mbit/s
         07:00      3.69 GiB |   88.48 GiB |   92.17 GiB |  219.92 Mbit/s
         08:00      3.88 GiB |   90.43 GiB |   94.31 GiB |  225.03 Mbit/s
         09:00      3.65 GiB |   86.15 GiB |   89.79 GiB |  214.25 Mbit/s
         10:00      3.20 GiB |   73.97 GiB |   77.17 GiB |  184.13 Mbit/s
         11:00      2.05 GiB |   31.39 GiB |   33.44 GiB |  191.49 Mbit/s
     ------------------------+-------------+-------------+---------------

Something strange with client 44663
Network issue on Sep 27 and it was temporarily limited to 80% (from 30000 KB/s to 24000)
And it is limited to 20000 in recent 3 hours

There was a brief issue with a backend update that made speedtests a bit wonky, but this should be fixed by now. It may take a bit of time before the current speeds have fully corrected.

I have client 45734, which is set to a max upload speed of 10000kb/s,
but I've noticed that it is only maxing out at 4194kb/s and the Hitrate has dropped dramatically.
This state has been going on for a week, is this normal?

I have client 45734, which is set to a max upload speed of 10000kb/s,
but I've noticed that it is only maxing out at 4194kb/s and the Hitrate has dropped dramatically.
This state has been going on for a week, is this normal?

Looks like your client experienced some overloads while it was at the higher speed, so it dropped down somewhat. This currently starts lifting after ten days or so.

Though there will be some updates to this part of the system in the near future to prevent the limit from lingering this long just for one or two overloads.

Was the hathrate calculation changed? Mine has dropped significantly from when I last checked a day or two ago and doesn't match the wiki (which may now be outdated).

Was the hathrate calculation changed? Mine has dropped significantly from when I last checked a day or two ago and doesn't match the wiki (which may now be outdated).

It hasn't changed, not intentionally anyway, but I've been messing a lot with the backend code recently so something might be broken. Which client, what are you getting, and what are you expecting it to be?

Edit: Actually there was one part about it that changed that I forgot about, it now applies the cap of 5 KB/s per range on the hath rate as well, since the variables it used to calculate the old cap don't exist anymore. If that explains it for you, then yes, it was intentional.

It hasn't changed, not intentionally anyway, but I've been messing a lot with the backend code recently so something might be broken. Which client, what are you getting, and what are you expecting it to be?

Edit: Actually there was one part about it that changed that I forgot about, it now applies the cap of 5 KB/s per range on the hath rate as well, since the variables it used to calculate the old cap don't exist anymore. If that explains it for you, then yes, it was intentional.

I think that cap explains it, then. Across all my clients, my hath rate is down by about a factor of 3.

I seem to be having some issues with my client, but I'm not sure where to start debugging the issue.

Excerpt from the logs:

2023-10-05T19:06:03Z [debug] Current system time is Thu Oct 05 21:06:03 CEST 2023 (1696532763479)
2023-10-05T19:06:03Z [debug] Certificate expires on Fri Oct 20 12:12:25 CEST 2023 (1697796745000)
2023-10-05T19:06:03Z [debug] Memory total=32768kB free=25250kB max=16457728kB
2023-10-05T19:06:13Z [debug] Memory total=32768kB free=25250kB max=16457728kB
2023-10-05T19:06:19Z [debug] {6451/192.168.128.1} The connection was interrupted or closed by the remote host.
2023-10-05T19:06:19Z [debug] Remote host terminated the handshake
2023-10-05T19:06:20Z [debug] {6452/192.168.128.1} File is not in static ranges for fileindex=<fileindex> xres=1280 fileid=<fileid>-1280-1818-jpg
2023-10-05T19:06:20Z [debug] Response Written:
2023-10-05T19:06:20Z [debug] An error has occurred. (404)
2023-10-05T19:06:20Z [info] {6452/192.168.128.1} Code=404 Bytes=28 GET /h/<fileid>-1280-1818-jpg/keystamp=<keystamp>;fileindex=<fileindex>;xres=1280/00012.jpg HTTP/1.1
2023-10-05T19:06:20Z [info] {6452/192.168.128.1} Code=404 Bytes=28 Finished processing request in 0.00 seconds

I've removed the particular fileid etc. The error "The connection was interrupted or closed by the remote host." and "Remote host terminated the handshake" seems to indicate a remote issue, but I suspect it's on my end. Could this error occur due to faulty file permissions? Port should be properly forwarded and the stillalive tests succeed without issue. What I'm noticing is that whenever the client gets assigned a P1 static range, the quality and trust suddenly start tanking. The cache does seem to slowly fill up, but not at the expected rate.

The client runs in a customized Docker container, based on "amazoncorretto:21-alpine" with the "--disable-ip-origin-check" flag enabled.

Edit: Forgot to mention, but the error log doesn't contain any recent logs.
Edit 2: Recreated it with host networking and without the "--disable-ip-origin-check" flag, going to test if that makes a difference.

This post has been edited by snieder: Oct 5 2023, 21:30

I seem to be having some issues with my client, but I'm not sure where to start debugging the issue.

I've removed the particular fileid etc. The error "The connection was interrupted or closed by the remote host." and "Remote host terminated the handshake" seems to indicate a remote issue, but I suspect it's on my end. Could this error occur due to faulty file permissions? Port should be properly forwarded and the stillalive tests succeed without issue. What I'm noticing is that whenever the client gets assigned a P1 static range, the quality and trust suddenly start tanking. The cache does seem to slowly fill up, but not at the expected rate.

Hm. Yeah, no, that's a problem with the backend. I had been tracking an issue with increased errors being flagged by the client monitor, and I believe I've found and fixed the problem now. Let me know if you're still seeing any problems, especially if you still get any of these errors:

CODE

2023-10-05T19:06:20Z [debug] {6452/192.168.128.1} File is not in static ranges for fileindex=<fileindex> xres=1280 fileid=<fileid>-1280-1818-jpg

Hm. Yeah, no, that's a problem with the backend. I had been tracking an issue with increased errors being flagged by the client monitor, and I believe I found and fixed the problem now. Let me know if you're still seeing any problems, especially if you still get any of these errors:

CODE

2023-10-05T19:06:20Z [debug] {6452/192.168.128.1} File is not in static ranges for fileindex=<fileindex> xres=1280 fileid=<fileid>-1280-1818-jpg

All right, thank you for the quick reply! Will do. Though it might take a while as it tanked my trust to -100 and quality to about 2.3k (slowly recovering) (IMG:[invalid] style_emoticons/default/tongue.gif). I'll keep it running in host mode without the flag for now as well.

Is there a way to check if my client has been overloading? I stopped gaining higher priority ranges over the last few days and the "session files served" count (i.e. date [info] {<this number>/ip}...) seems like it reset in the last 30 mins or so. Are the two things related or am I capped out at this range count now?

This post has been edited by nasu: Oct 5 2023, 22:18

All right, thank you for the quick reply! Will do. Though it might take a while as it tanked my trust to -100 and quality to about 2.3k (slowly recovering) (IMG:[invalid] style_emoticons/default/tongue.gif). I'll keep it running in host mode without the flag for now as well.

Oh. Well, I reset the trust of your client, so it should be fine now.

Is there a way to check if my client has been overloading? I stopped gaining ranges over the last few days and the "session files served" count (i.e. date [info] {<this number>/ip}...) seems like it reset in the last 30 mins or so. Are the two things related or am I capped out at this range count now?

There's no readout for overloads, no, but it hasn't been. Your range count is at 6000, which is indeed the cap.

The "session files served" counter resets if the internal HTTP server restarts due to a cert refresh, which happens every three months or so.