[X] My Assistant

Hi. Why my H@H was die before restart?

2025-02-08T02:40:52Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:42:42Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:44:32Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:46:22Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:48:12Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:50:02Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:51:52Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:53:42Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:55:32Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:57:22Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
2025-02-08T02:59:12Z [WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later
^[[A ^C2025-02-08T02:59:23Z [info] Shutting down...
2025-02-08T02:59:23Z [WARN] Server reported expired key; attempting to refresh time from server and retrying
^C^C^C2025-02-08T02:59:24Z [info] Shutdown in progress - please wait up to 30 seconds
^C2025-02-08T02:59:29Z [info] ServerSocket was closed and will no longer accept new connections.
2025-02-08T02:59:29Z [info] Your business is appreciated
hath@VPS:~$ java -jar HentaiAtHome.jar
2025-02-08T03:00:38Z [info] Hentai@Home 1.6.4 (Build 176) starting up
2025-02-08T03:00:38Z [info] Copyright © 2008-2024, E-Hentai.org - all rights reserved.
2025-02-08T03:00:38Z [info] This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v3 license.
2025-02-08T03:00:38Z [info] Loaded login settings from client_login
2025-02-08T03:00:38Z [info] Connecting to the Hentai@Home Server to register client with ID *****...
2025-02-08T03:00:39Z [info] Reading Hentai@Home client settings from server...
2025-02-08T03:00:39Z [info] Applying settings...
2025-02-08T03:00:39Z [info] Logging ended.
2025-02-08T03:00:39Z [info] Finished applying settings
2025-02-08T03:00:39Z [info] CacheHandler: Attempting to load persistent cache data...
2025-02-08T03:00:39Z [info] CacheHandler: All persistent fields found, loading remaining objects
2025-02-08T03:00:39Z [info] CacheHandler: Loaded static range ages
2025-02-08T03:00:39Z [info] CacheHandler: Loaded LRU cache
2025-02-08T03:00:39Z [info] CacheHandler: Successfully loaded persistent cache data
2025-02-08T03:00:39Z [info] Requesting certificate from server...
2025-02-08T03:00:40Z [info] Starting up the internal HTTP Server...
2025-02-08T03:00:40Z [info] Internal HTTP Server was successfully started, and is listening on port 8443
2025-02-08T03:00:40Z [info] Notifying the server that we have finished starting up the client...
2025-02-08T03:00:42Z [info] {1/37.48.81.219} Code=200 Bytes=36 GET /servercmd/still_alive//1739031634/a98a66d9bedbc8624b3d2ee694994671785af33d HTTP/1.1
2025-02-08T03:00:42Z [info] {1/37.48.81.219} Code=200 Bytes=36 Finished processing request in 0.00 seconds
2025-02-08T03:00:42Z [info] {2/37.48.81.219} Code=200 Bytes=2500002 GET /servercmd/speed_test/testsize=2500002/1739031635/c60ab8621494319eecde0baed21e3f941474a256 HTTP/1.1
2025-02-08T03:00:42Z [info] {3/37.48.81.219} Code=200 Bytes=2500001 GET /servercmd/speed_test/testsize=2500001/1739031635/ca2e0a293b14c26ea047ac63dd354ff204f8de3d HTTP/1.1
2025-02-08T03:00:43Z [info] {3/37.48.81.219} Code=200 Bytes=2500001 Finished processing request in 0.61 seconds (4105.09 KB/s)
2025-02-08T03:00:43Z [info] {2/37.48.81.219} Code=200 Bytes=2500002 Finished processing request in 0.62 seconds (4006.41 KB/s)
2025-02-08T03:00:44Z [info] {4/37.48.81.219} Code=200 Bytes=5000003 GET /servercmd/speed_test/testsize=5000003/1739031636/838b77b4df63cf5e817d2dbe25d7e28ea446ae50 HTTP/1.1
2025-02-08T03:00:44Z [info] {6/37.48.81.219} Code=200 Bytes=5000001 GET /servercmd/speed_test/testsize=5000001/1739031636/b430b679db1de94bbbbebad4b07289cbfb8cfbdd HTTP/1.1
2025-02-08T03:00:44Z [info] {5/37.48.81.219} Code=200 Bytes=5000002 GET /servercmd/speed_test/testsize=5000002/1739031636/13945570fc0135345a187efbd1334518cd8e2173 HTTP/1.1
2025-02-08T03:00:44Z [info] {4/37.48.81.219} Code=200 Bytes=5000003 Finished processing request in 0.52 seconds (9560.24 KB/s)
2025-02-08T03:00:44Z [info] {6/37.48.81.219} Code=200 Bytes=5000001 Finished processing request in 0.55 seconds (9124.09 KB/s)
2025-02-08T03:00:44Z [info] {5/37.48.81.219} Code=200 Bytes=5000002 Finished processing request in 0.56 seconds (8849.56 KB/s)
2025-02-08T03:00:46Z [info] {8/37.48.81.219} Code=200 Bytes=5000001 GET /servercmd/speed_test/testsize=5000001/1739031638/5c91f4b4378ed0183e2de21a864224bd48b38f28 HTTP/1.1
2025-02-08T03:00:46Z [info] {11/37.48.81.219} Code=200 Bytes=5000002 GET /servercmd/speed_test/testsize=5000002/1739031638/9ef26308d6bb86626d6998c4f803282065626fea HTTP/1.1
2025-02-08T03:00:46Z [info] {7/37.48.81.219} Code=200 Bytes=5000003 GET /servercmd/speed_test/testsize=5000003/1739031638/a3dd606899e5412e720b04fcc9513379df9bd8cd HTTP/1.1
2025-02-08T03:00:46Z [info] {9/37.48.81.219} Code=200 Bytes=5000004 GET /servercmd/speed_test/testsize=5000004/1739031638/b14a7e7b0fcaf7c7e86679cf364c1481f8f139e5 HTTP/1.1
2025-02-08T03:00:46Z [info] {10/37.48.81.219} Code=200 Bytes=5000005 GET /servercmd/speed_test/testsize=5000005/1739031638/f33c0ae1116d2d2445a3e9d83eeb4b53d2a222e0 HTTP/1.1

Hi. Why my H@H was die before restart?

Unless you waited 13 hours before posting that, your computer's clock is off by 13 hours and change, or the time zone is wrong. H@H will compensate to some extent, but you could run into issues if it changes abruptly or drifts a lot.

deleted

This post has been edited by sdgwetgs: Feb 8 2025, 20:41

So fix your clock then? NTP obviously isn't working, it's off by 13 hours.

So fix your clock then? NTP obviously isn't working, it's off by 13 hours.

Yes. I installing ntp on all H@H servers now

Is there a rough guideline for an optimal "storage to data transfer limit" ratio for a H@H node?

Like between a node with large disk space (1-2 TB) but lower data transfer limit (<5 TB), and lower storage (100-200 GB) but lots of data transfer (10-20 TB), would one be more beneficial (or generate more Hath)? Obviously unlimited data transfer is ideal but not always possible.

Is there a rough guideline for an optimal "storage to data transfer limit" ratio for a H@H node?

Like between a node with large disk space (1-2 TB) but lower data transfer limit (<5 TB), and lower storage (100-200 GB) but lots of data transfer (10-20 TB), would one be more beneficial (or generate more Hath)? Obviously unlimited data transfer is ideal but not always possible.

Hard to give a concise answer, since it varies a lot by region and how old the client is. Traffic per range varies by a factor of 100 between the lowest-traffic region and the highest-traffic one. For the low-traffic regions like Oceania and South America, you won't get much traffic unless you have a lot of ranges, which means you need a lot of disk space.

These numbers are a bit higher than the real ones, but I can give some rough numbers for the main regions based on the bandwidth limiter estimates. For Asia, clients average around 8.5 KB/s per assigned P1 range, each of which requires 500 MB of assigned space. Followed by North America with around 2.4 KB/s per P1 range, and Europe with around 1.4 KB/s per P1 range. But there won't generally be enough assignable P1 ranges to make full use of a large cache, so a fast connection with a smaller SSD will probably perform better than a slow connection with a larger HDD.

thanks for the hard work like always

My client is having two problems.

First one is that sometimes the client using all CPU power available, when this happens the ram usage is still normal, client taking requests as usual, and no special error log, but would cause my computer overheating so I have to restart the client. This never happened in the further past but already happened 2-3 time in the last few days, and only after the client is running for a while. The logs from these sessions are already rotated so I’m not able to provide them, but I can do it if that happens again.

Second one is that the quality dropped from almost full to sub-100 yesterday, not sure if that's related to the first problem (or the things that I did to try to solve it).

I have considered or done these so far:
Is a 2 core and 512MB VM not enough for the client?
- I don’t think so, it’s been running with this spec in the past month and doing well, so I leave that unchanged.

Cache corrupted or low disk performance?
- Done few full rescans, which all running at 1 to 1.2 GB/s according to system monitoring tools, and the client starts normally afterwards, trust is still 1000.

Internet speed problem?
- Speed test still showing 1Gbps up and down, and my client reports 96000KB/s speed.

Network settings on my VM or host machine?
- My other network related service in the same VM working as usual, I also have not done any related software updates recently.

Port forwarding problem?
- I checked the settings in my router, everything matches, also tested it using the tool on www.yougetsignal.com whilst the client is running which reported the port is open. But I still changed it in case there’s some other problem related to that specific port, repeated the above procedure, but still makes no difference to the situation.

IP problem?
- I did indeed changed my IP few times recently because of various reasons not related to H@H and I make sure the client is not running when doing that.


Now, should I just wait and see if it recovers? Because I’m worried about my ranges being taken away for being unhealthy.

Thank you.


EDIT: It seems it is now slowly recovering when I’m typing this post, but I’ll still keep an eye on it for a while.

This post has been edited by CXPM: Mar 4 2025, 07:40

If your CPU is pegged at 100% and your quality drops, that just means the CPU is not powerful enough to handle the current traffic. TLS encryption does take some processing, and "2 core" is meaningless without knowing what cores you are talking about.

Solutions include using a more powerful system, or dropping the maximum speed.

The host is Apple Mac mini with M4 CPU, Hypervisor is VMware Fusion, everything is ARM architecture. By default it uses both P-cores and E-cores depending on the usage.

When the client is running normally it uses no more than 10% of (the allocated virtual) CPU power, when doing cache rescan it is about 30%. I have been running the client with this setting for more than a month, everything is fine until the problem occurs in the past few days. Which is why I suspect that there’s some other reason causing it instead of bottleneck.

That being said, I’ll change it to 4 cores when the next time I need a restart, and see what happens.

The Apple M4 should be overkill, when you said "2 core" I was picturing a 1st-gen Raspberry Pi from 2012, which some people have tried to use in the past. So yeah, then it's probably something else going wrong.

Not sure what JVM you are using, and I'm not really familiar with what is available for ARM + MacOS, but you could try switching to a different JVM and see if it still happens.

The guest OS is Debian 12 with openjdk 17.0.14, I’m also not familiar with MacOS enough to host directly on it, so I pack everything in a Linux VM for easier management and migration when needed (IMG:[invalid] style_emoticons/default/wink.gif)

Could be java acting weird yeah, time to look for another choice whilst waiting for the client to recover…


EDIT:
Sigh, happened again twice, I've switched java to Temurin 21.0.6, virtual CPU to 4 cores, memory to 768MB, now it is eating all 4 cores, and still no special logs I can find. I'm now temporary moved the VM to E-cores only to reduce affect to the host and just keep it running until my quality going back to 9000 again than think what to do next, I really don't want to restart it that often.

This post has been edited by CXPM: Mar 4 2025, 18:05

`java.nio.file.NoSuchFileException` issue when download archive of particular gallery.

```
2025-03-07T01:33:19Z [WARN] Exhaused retries or aborted getting [175.110.112.9] http://175.110.112.9/om/177830252/77bdb922...67p1lmh3/hathdl
2025-03-07T01:33:24Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000190.webp
2025-03-07T01:33:24Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:24Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000190.webp
2025-03-07T01:33:24Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:24Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000190.webp
2025-03-07T01:33:24Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:24Z [WARN] Exhaused retries or aborted getting [46.21.146.190] http://46.21.146.190/om/177830253/ead83027...x0q1lmh4/hathdl
2025-03-07T01:33:30Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000191.webp
2025-03-07T01:33:30Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:30Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000191.webp
2025-03-07T01:33:30Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:30Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000191.webp
2025-03-07T01:33:30Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:30Z [WARN] Exhaused retries or aborted getting [175.110.112.9] http://175.110.112.9/om/177830254/c8fd9342...vr11lmh4/hathdl
2025-03-07T01:33:35Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000028.webp
2025-03-07T01:33:35Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:35Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000028.webp
2025-03-07T01:33:35Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:35Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000028.webp
2025-03-07T01:33:35Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:35Z [WARN] Exhaused retries or aborted getting [46.21.146.190] http://46.21.146.190/om/143224310/07d92094...u9g1lmh4/hathdl
2025-03-07T01:33:40Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000029.webp
2025-03-07T01:33:40Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:40Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000029.webp
2025-03-07T01:33:40Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:40Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000029.webp
2025-03-07T01:33:40Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:40Z [WARN] Exhaused retries or aborted getting [185.107.57.2] http://185.107.57.2/om/143224312/657c63ba7...9gq1lmh4/hathdl
2025-03-07T01:33:45Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000030.webp
2025-03-07T01:33:45Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:45Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000030.webp
2025-03-07T01:33:45Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:46Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000030.webp
2025-03-07T01:33:46Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:46Z [WARN] Exhaused retries or aborted getting [175.110.112.9] http://175.110.112.9/om/177829809/28df1af9...xd31lmh4/hathdl
2025-03-07T01:33:51Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000031.webp
2025-03-07T01:33:51Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:51Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000031.webp
2025-03-07T01:33:51Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:51Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000031.webp
2025-03-07T01:33:51Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:51Z [WARN] Exhaused retries or aborted getting [185.107.57.2] http://185.107.57.2/om/177829813/9e1bcd0ec...ouy1lmh4/hathdl
2025-03-07T01:33:56Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000032.webp
2025-03-07T01:33:56Z [WARN] Retrying.. (2 tries left)
2025-03-07T01:33:56Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000032.webp
2025-03-07T01:33:56Z [WARN] Retrying.. (1 tries left)
2025-03-07T01:33:56Z [WARN] java.nio.file.NoSuchFileException: download/[無名老圖] 葬送のフリーレン短篇合集 ［个人整理中］ [3261559-1280x]/00000032.webp
2025-03-07T01:33:56Z [WARN] Retrying.. (0 tries left)
2025-03-07T01:33:56Z [WARN] Exhaused retries or aborted getting [185.107.57.2] http://185.107.57.2/om/177829816/948bd2752...cg51lmh4/hathdl
```

when download archive of other gallery, it's fine.

Hentai@Home 1.6.4 (Build 176)

openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu118.04)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu118.04, mixed mode, sharing)

`java.nio.file.NoSuchFileException` issue when download archive of particular gallery.

when download archive of other gallery, it's fine.

Hentai@Home 1.6.4 (Build 176)

openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu118.04)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu118.04, mixed mode, sharing)

Works for me. Most likely your OS/filesystem is choking on the unicode. Check that your locale is set to UTF-8.

So I somewhat solved the CPU problem, I stumbled into a blog post from 2023 mentioned a similar situation, which from my understanding was caused by corrupted cache when there are 0 size file(s). But the problems were, I can’t find any 0 size files in my cache, rescan runs fine, filesystem check runs fine, and debugging it myself is beyond my skills. And this should have been fixed in version 1.6.2 according to the changelog.

So I just tried a stupid method, just in case the hypervisor doing weird things: I extracted everything out of the virtual disk, ran the client and rescan for a while directly on macos, and it works fine, after that I tuck everything back, another rescan and such, so far so good. I still don't know the actual cause of the problem, though.

However, the quality droppijg problem still persists. I noticed that it has a pattern, it would go back and forth between zero and mid-8000 like a wave. I thought it was because of peak internet hours (Hong Kong, timezone GMT+8) but it would drop in midnight~dawn hours, and increase in the evening~night hours so... I have no idea now.

EDIT: Never mind, happened again lol

This post has been edited by CXPM: Mar 11 2025, 18:01

I hope you can continue to update, it is very helpful to me

thanks for the hard work like always

I have a question. Today I upgraded my wifi and can access my H@H normally. However, after I restart H@H several times, it asks me to input "Client ID and Key" repeatedly, which makes it impossible to start normally：
2025-03-14T13:43:05Z [info] Reading Hentai@Home client settings from server...
2025-03-14T13:43:06Z [WARN]
2025-03-14T13:43:06Z [WARN] Authentication failed, please re-enter your Client ID and Key (Code: FAIL_STARTUP_LOOP)
2025-03-14T13:43:06Z [info] Before you can use this client, you will have to register it at https://e-hentai.org/hentaiathome.php
2025-03-14T13:43:06Z [info] IMPORTANT: YOU NEED A SEPARATE IDENT FOR EACH CLIENT YOU WANT TO RUN.
2025-03-14T13:43:06Z [info] DO NOT ENTER AN IDENT THAT WAS ASSIGNED FOR A DIFFERENT CLIENT UNLESS IT HAS BEEN RETIRED.
2025-03-14T13:43:06Z [info] After registering, enter your ID and Key below to start your client.
2025-03-14T13:43:06Z [info] (You will only have to do this once.)
Enter Client ID:

FAIL_STARTUP_LOOP

means your client failed to start up more than 10 times in a row without staggering the startup delay. Wait more than 15 minutes and try again.