[X] My Assistant

I've had a hardware failure, but with no data loss causing my clients to go down for several days. However, on starting them back up the trust quickly falls to 0 and oscillates between -10 and 10, quality is unaffected. I don't see anything immediately obvious as to what's wrong and these clients have been running with this configuration for years. Is this expected behavior or is there a problem that I'm not seeing?


ID: 30653 and 30655

Thanks,

It can happen when high-traffic clients have been offline for more than a week as in your case, and therefore lack most of the recent files. Give them a few days.

ID 46806 here. My client quality drop to very low (~10), it could increase to a normal value (~2000) but would drop again in the same day. How can i fix these problem?

If your quality drops that low, it just means you have a lot of load failures compared to your traffic. Which is usually caused by network issues or an overloaded system.

Client 47540, i have been running for about 250h, quality 10000 and only 23 received/cached files and zero files served. I assume something goes wrong, but i have no clue what.

Client 47540, i have been running for about 250h, quality 10000 and only 23 received/cached files and zero files served. I assume something goes wrong, but i have no clue what.

Like it says in the welcome message, it can take several weeks before you start seeing any real traffic.

Oh ok, i thought it said something about days, my bad.

heya,

is there something wrong lately, I'm getting strange peaks since yesterday.
like completely flat lines with the usual peaks. the strange thing is the completely flat line.
I restarted my client, and in 3h I got 1 file sent, and 0 received. that's unusual.

regards

edit : just saw the quality, 14, wtf happened oÔ;;
edit2 : dunno what happened exactly but looks like it solved itself.

edit3 : and since I'm here, what's the "allow removing static ranges if necessary" good for ?

When you reduce your client's disk cache size, maximum upload rate for instance, or setting a monthly data transfer target. Your static range allocation is limited based on these values.

I don't think you need to worry about it unless you have been explicitly told to tick that box with your new settings.

ok thanks.

This post has been edited by machinman: Mar 10 2024, 20:34

edit3 : and since I'm here, what's the "allow removing static ranges if necessary" good for ?

When you reduce your client's disk cache size, maximum upload rate for instance, or setting a monthly data transfer target. Your static range allocation is limited based on these values.

I don't think you need to worry about it unless you have been explicitly told to tick that box with your new settings.

EDIT2: Unfortunately, another submarine cable failure occurred one day after the ISP fixed the issue…

EDIT: My ISP has fixed the connectivity issue, but it may happen again in the future, it would be nice if there was a solution.

Due to a submarine cable failure, one of my clients was unable to connect to the RPC server(97% packet loss). Is there any other way to solve this problem other than waiting for the ISP to adjust and fix it?
I can connect to RPC through a proxy, but this will cause the IP to change to the proxy's. Is it possible to add an option to manually specify the client IP?
Or maybe the RPC server can be distributed to different hosting providers similar to the image servers? This can avoid being unable to connect to any RPC server due to routing problems.

This post has been edited by james58899: Mar 13 2024, 07:02

heya,

I had a strange error earlier.

CODE

[WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later

any idea what could have caused that ?
everything seemed fine on my side. When I saw that error, I just hit the refresh settings

CODE

[WARN] Server reported expired key; attempting to refresh time from server and retrying

and it seems it fixed it just like that.

edit : actually I just noticed something, that pc was one hour late, we switched for summer hours yesterday, and it seems it didn't get the memo. anyway, I did just like I said and it fixed the problem, I synched the hour after it was fixed, but it must have been related somehow, obviously.

edit 2 : thanks for the input kamio11

This post has been edited by machinman: Apr 2 2024, 19:10

heya,

I had a strange error earlier.

CODE

[WARN] Failed stillAlive test: (KEY_EXPIRED) - will retry later

any idea what could have caused that ?
everything seemed fine on my side. When I saw that error, I just hit the refresh settings

CODE

[WARN] Server reported expired key; attempting to refresh time from server and retrying

and it seems it fixed it just like that.

edit : actually I just noticed something, that pc was one hour late, we switched for summer hours yesterday, and it seems it didn't get the memo. anyway, I did just like I said and it fixed the problem, I synched the hour after it was fixed, but it must have been related somehow, obviously.

This happens when the clock on the computer running your H@H client gets sufficiently out of sync with what the EH control servers expect. Restarting the client or refreshing the settings typically fixes this.

thank you for the work

so I was re-reading the hentai@home wiki, and it's suggested that ssd are ideal.
my question is why ? I mean, I kinda know the differences, but what makes it better for hentai@home specifically ? I suppose it's I/O related and hdd speed limitations but I'm curious.

also what's the max allocated space I should set, from what I understand, there's no point in serving more than 1,5TB right ? but I'm no good when it comes to math, so please be free to correct my assumption and calculations ;p

so I was re-reading the hentai@home wiki, and it's suggested that ssd are ideal.
my question is why ? I mean, I kinda know the differences, but what makes it better for hentai@home specifically ? I suppose it's I/O related and hdd speed limitations but I'm curious.

You would need a very high traffic client before it makes any different performance-wise.

also what's the max allocated space I should set, from what I understand, there's no point in serving more than 1,5TB right ? but I'm no good when it comes to math, so please be free to correct my assumption and calculations ;p

It can use more than that now with high-capacity ranges, though it's hard to say exactly how much more since it depends on other factors and other clients. You can always assign a smaller cache size at first, the increase it later if it caps out and stops assigning/promoting your ranges.

ok thanks for the input.

I guess my traffic won't be that demanding before a long time...
it was set to 8TB so I could just use a 2 or 4TB ssd since my HDD might be needed elsewhere, I guess I'll lower the space and move the files soon...

best regards

1.6.3 was released. This is a recommended update due to a potential resource exhaustion issue.

- Added experimental proxy support for backend image server requests. This allows you to use a SOCKS (v4 or v5) or HTTP proxy if connectivity to the image servers is unreliable, which is mostly relevant in regions with heavy internet censorship.

This adds three arguments that can be passed on startup:

--image-proxy-host=<host> - hostname or IP address for the proxy
--image-proxy-type=<type> - can be "socks" or "http". defaults to "socks" if not provided
--image-proxy-port=<port> - the port of the proxy. defaults to 1080 for SOCKS and 8080 for HTTP if not provided

It does not support proxies that require authentication.

While it will technically work to use Tor as a SOCKS proxy, this should be avoided as Tor is too slow for this purpose.

- The currently selected RPC server will no longer reset when the server list is refreshed, as long as the current server is still in the list. This should make the --rpc-server-ip argument more useful.

- Improved reliability of reading HTTP request headers with some browser/locale combinations.

- Corrected a potential resource exhaustion issue.

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

Thanks a lot for the update!

This post has been edited by ddvd: May 13 2024, 07:44

Recently, I tried to enable a screensaver on my computer, but it doesn't seem to ever start despite being at the minimum time (1 minute).
I wonder if that could come from H@H?
Would need other people to test to know (IMG:[invalid] style_emoticons/default/mellow.gif)

1.6.3 was released. This is a recommended update due to a potential resource exhaustion issue.

- Added experimental proxy support for backend image server requests. This allows you to use a SOCKS (v4 or v5) or HTTP proxy if connectivity to the image servers is unreliable, which is mostly relevant in regions with heavy internet censorship.

This adds three arguments that can be passed on startup:

--image-proxy-host=<host> - hostname or IP address for the proxy
--image-proxy-type=<type> - can be "socks" or "http". defaults to "socks" if not provided
--image-proxy-port=<port> - the port of the proxy. defaults to 1080 for SOCKS and 8080 for HTTP if not provided

It does not support proxies that require authentication.

While it will technically work to use Tor as a SOCKS proxy, this should be avoided as Tor is too slow for this purpose.

- The currently selected RPC server will no longer reset when the server list is refreshed, as long as the current server is still in the list. This should make the --rpc-server-ip argument more useful.

- Improved reliability of reading HTTP request headers with some browser/locale combinations.

- Corrected a potential resource exhaustion issue.

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

Hi Tenboro. An observation, when I tried to update one of my boxes from 1.6.2 to 1.6.3, it failed to come up, and the error log was being continuously filled with the following message:

[WARN] CacheHandler: Expected static range directory cache/a2/e1 could not be accessed

I didn't see that particular directory at all when I navigated to cache/a2/. What I had was cache/a2/27. Rolling back to 1.6.2 worked fine. I updated my other boxes successfully, then retried downloading 1.6.3 on the problematic machine, and relaunching it, it worked fine the second time. Not sure what the root cause may have been, but just an FYI.