[X] My Assistant

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.

It's possible it hit some sort of temporary filesystem read error, but it looks like in those cases it would just loop and try to access that same directory again. It doesn't have anything to do with 1.6.3, but I'll make to a note to avoid that.

There is a little problem in my client, about the network and proxy.
I deploy the HAH client on my home server, and set a proxy on the gateway so that all my inner network deivce can be proxy.
The problem is: HAH server has got the proxy ip ,not my real public ip. Then I put rpc-server domain to the "Direct List" on my proxy program, but it's useless. For that I read the source code of HAH, and undersand that client will make a request to the server and get an ip-list (rpc-server-ip), then use it for server to check the client ip. The ip-list is dynamis so I have to always check and put them to the "Direct List"(useful and fast). Otherwise every "refresh-setting" will get the wrong client ip make my income request fail.
I've try to set a forward on my proxy server but it's too slow and watste lots of flow.
Is there any way such as --disable-rpc-server-ip or other to solve this? Or if I can set the domain to the --rpc-server-ip for disable that dynamic ip list?

welp, I updated and changed to a ssd so I won't be able to compare and say precisely what did what, but I do get nicer and round graphic charts now it seems, somewhat.
with a functional hdd, I would get peaks way down regularly, now it seems smoother and give better average upload speed... who knows. maybe I just want to see a difference (IMG:[invalid] style_emoticons/default/tongue.gif)

This post has been edited by machinman: May 20 2024, 18:25

Hi, i closed the client1.6.2 and automatically saved the pcache_ages_info_lru file. However, upon restarting, it forced a cache verification which took over two days to complete (previously it took about six hours).
And then displayed a connection failure resulting in startup failure.
After updating to v1.6.3, it still requires a forced cache verification and is extremely slow.
At the same time, I noticed that when closing the client normally, the system often fails to save the pcache_ages_info_lru file, resulting in a significant amount of time spent on verification upon startup.
Is an issue with my operation or if this is a new feature of the new client?Thanks.

If the monitoring system detects cache file corruption on your client, it will set it to perform a full cache verification on the next startup. This takes longer than the standard cache rescan that happens if it isn't shut down properly, since it verifies the integrity of every single file, but it should only happen once, assuming you let it finish.
(If it finished the scan but failed to start up for some reason, you can uncheck the "Verify cache integrity on next startup" box on the settings page.)

It worked.Thanks

This post has been edited by shuaishuai1: May 25 2024, 16:09

Hi, i closed the client1.6.2 and automatically saved the pcache_ages_info_lru file. However, upon restarting, it forced a cache verification which took over two days to complete (previously it took about six hours).
And then displayed a connection failure resulting in startup failure.
After updating to v1.6.3, it still requires a forced cache verification and is extremely slow.

If the monitoring system detects cache file corruption on your client, it will set it to perform a full cache verification on the next startup. This takes longer than the standard cache rescan that happens if it isn't shut down properly, since it verifies the integrity of every single file, but it should only happen once, assuming you let it finish.

(If it finished the scan but failed to start up for some reason, you can uncheck the "Verify cache integrity on next startup" box on the settings page.)

At the same time, I noticed that when closing the client normally, the system often fails to save the pcache_ages_info_lru file, resulting in a significant amount of time spent on verification upon startup.

Don't think anyone have reported anything of the sort, and there weren't any changes in this mechanism in 1.6.3. If it shuts down normally without saving the pcache files, make sure to save the logs and send them to me, and I'll take a look at it.

Hello, my family 1.6.3H@H seems to report errors every once in a while (IMG:[invalid] style_emoticons/default/cry.gif) , but because it has only been running for a month, I still don’t know the reason. The log_err.old file records repeated error content similar to the following:

2024-05-27T05:11:41Z [WARN] Note: A common reason for this is running firewalls with outgoing restrictions or programs like PeerGuardian/PeerBlock. Verify that the remote host is not blocked.
2024-05-27T05:11:42Z [WARN] Request host did not send Content-Length, aborting transfer. 90- 5760-3240-jpg/6ba812740415211d6bc6815bf5c9aaa249793ded-131366-1280-720-jpg/1280/h7n5ubsf84nsbb1cv36/hathrequest-48038)

Hello, my family 1.6.3H@H seems to report errors every once in a while (IMG:[invalid] style_emoticons/default/cry.gif) , but because it has only been running for a month, I still don’t know the reason. The log_err.old file records repeated error content similar to the following:

2024-05-27T05:11:41Z [WARN] Note: A common reason for this is running firewalls with outgoing restrictions or programs like PeerGuardian/PeerBlock. Verify that the remote host is not blocked.
2024-05-27T05:11:42Z [WARN] Request host did not send Content-Length, aborting transfer. 90- 5760-3240-jpg/6ba812740415211d6bc6815bf5c9aaa249793ded-131366-1280-720-jpg/1280/h7n5ubsf84nsbb1cv36/hathrequest-48038)

Your client 48038 looks fine. Most likely it's caused by network blocking on the other host or between you and the other host, which is somewhat expected in that region.

Your client 48038 looks fine. Most likely it's caused by network blocking on the other host or between you and the other host, which is somewhat expected in that region.

Okay (IMG:[invalid] style_emoticons/default/smile.gif) , I'll keep watching it. Maybe the log I provided is not the main reason, because when I noticed the exception, H@H's trust had already reached -100

So far this month, my local ISP service hasn't been very stable, often going offline for more than 24 hours. Will this result in my h@h client being revoked? (IMG:[invalid] style_emoticons/default/cry.gif) (IMG:[invalid] style_emoticons/default/cry.gif)
(It has been disconnected more than 5 times since 17 May)

So far this month, my local ISP service hasn't been very stable, often going offline for more than 24 hours. Will this result in my h@h client being revoked? (IMG:[invalid] style_emoticons/default/cry.gif) (IMG:[invalid] style_emoticons/default/cry.gif)
(It has been disconnected more than 5 times since 17 May)

There's no immediate danger of that, but it could happen if it goes on for a long time. You can generally just PM me if that happens and you were having actual technical problems, though.

Nice to see this project is still going, and going strong!

looks like H@H runners with malicious intend can just modify their cache file to make their bad-faith content to be reflected on the gallery system, that means they could spread trojan in the same way? May be there should be an update to patch this.

looks like H@H runners with malicious intend can just modify their cache file to make their bad-faith content to be reflected on the gallery system, that means they could spread trojan in the same way? May be there should be an update to patch this.

The system already detects and blocks this sort of behavior.

Hello, my family 1.6.3H@H seems to report errors every once in a while (IMG:[invalid] style_emoticons/default/cry.gif) , but because it has only been running for a month, I still don’t know the reason. The log_err.old file records repeated error content similar to the following:

2024-05-27T05:11:41Z [WARN] Note: A common reason for this is running firewalls with outgoing restrictions or programs like PeerGuardian/PeerBlock. Verify that the remote host is not blocked.
2024-05-27T05:11:42Z [WARN] Request host did not send Content-Length, aborting transfer. 90- 5760-3240-jpg/6ba812740415211d6bc6815bf5c9aaa249793ded-131366-1280-720-jpg/1280/h7n5ubsf84nsbb1cv36/hathrequest-48038)

Ohhh Nice to meet you my friend, this problem had occurred on my server before. I guess the reason is that my regional network block the outgoing-connection. So I deploy a proxy server on my gateway then this problem has disappeared.

If it's rarely occured on you server, then maybe the caused by target node, like the other's firewall, usual don't care. But if it's always occured, you should do something like proxy, otherwise it will lead to the reduce of Trust, never stop, that I have been through.

Hope to be helpful.

There is a little problem in my client, about the network and proxy.
I deploy the HAH client on my home server, and set a proxy on the gateway so that all my inner network deivce can be proxy.
The problem is: HAH server has got the proxy ip ,not my real public ip. Then I put rpc-server domain to the "Direct List" on my proxy program, but it's useless. For that I read the source code of HAH, and undersand that client will make a request to the server and get an ip-list (rpc-server-ip), then use it for server to check the client ip. The ip-list is dynamis so I have to always check and put them to the "Direct List"(useful and fast). Otherwise every "refresh-setting" will get the wrong client ip make my income request fail.
I've try to set a forward on my proxy server but it's too slow and watste lots of flow.
Is there any way such as --disable-rpc-server-ip or other to solve this? Or if I can set the domain to the --rpc-server-ip for disable that dynamic ip list?

The check for ensuring fileId in static range seems to be removed. Is this intended?

The check for ensuring fileId in static range seems to be removed. Is this intended?

Yes, it was redundant and was a cause for occasional failures.

Due to network fluctuations, H@H stops working from time to time because I cannot access other clients. If I set it to restart H@H every 3 days, will it be considered an abnormal state?

Ohhh Nice to meet you my friend, this problem had occurred on my server before. I guess the reason is that my regional network block the outgoing-connection. So I deploy a proxy server on my gateway then this problem has disappeared.

If it's rarely occured on you server, then maybe the caused by target node, like the other's firewall, usual don't care. But if it's always occured, you should do something like proxy, otherwise it will lead to the reduce of Trust, never stop, that I have been through.

Hope to be helpful.

I'm glad for your answer. This is a solution, but it seems that after deployment, the obtained IP will be the proxy IP, and an error will occur. (IMG:[invalid] style_emoticons/default/smile.gif)

I'm glad for your answer. This is a solution, but it seems that after deployment, the obtained IP will be the proxy IP, and an error will occur. (IMG:[invalid] style_emoticons/default/smile.gif)

There's also a solution for this problem, cause occured on my server too.
Logically, the client will request the service first, the server will obtain the client ip, then use it for other nodes's connection. So if you use the proxy, the service will obtain the proxy ip, as we known it's not true.
According to this, you can put the rpc-server-ip into "Direct List" of your proxy programme, then the client will not use the proxy ip but the real ip to request the server.

Perhaps the rpc-server-ip is different for different people, but you can find it in the starter log.

Example:

CODE

2024-05-14 17:56:30 [INFO] Hentai@Home 1.6.3 (Build 169) starting up
2024-05-14 17:56:30 [INFO] Copyright (c) 2008-2024, E-Hentai.org - all rights reserved.
2024-05-14 17:56:30 [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.
2024-05-14 17:56:30 [INFO] Loaded login settings from client_login
2024-05-14 17:56:30 [INFO] Connecting to the Hentai@Home Server to register client with ID ******...
2024-05-14 17:56:30 [DEBUG] Connecting to 94.100.24.67...
2024-05-14 17:56:30 [DEBUG] Reading 68 bytes from http://94.100.24.67/15/rpc?clientbuild=169&act=server_stat
2024-05-14 17:56:30 [DEBUG] Finished download for http://94.100.24.67/15/rpc?clientbuild=169&act=server_stat in 0 ms, writeoff=68, successful=yes
2024-05-14 17:56:30 [DEBUG] Received response: OK

You can find the line "2024-05-14 17:56:30 [DEBUG] Connecting to 94.100.24.67...". This ip is rpc-server-ip.
There will be 2 or 3 ips actually (in the source code, i debugged and found they are 94.100.24.67,94.100.24.68,94.100.24.69), and client use one of them, so you can put ip/mask into your direct-list (like 94.100.24.0/24).
BTW you'd better shutdown your proxy program and start the hah client by once to get the rpc-server-ip so that the client can use your real-ip to request the server, then get the correct rpc-server-ip, though I'm not sure it's necessary.

For that, the server will obtain the real-ip of your client, and you can check it at your hah homepage.

You can try it, at least it's useful for me.

This post has been edited by lz4515: Jun 27 2024, 14:30