[X] My Assistant

Also, I was reading through wiki and forum as well as online source. Some online source says to not use 443 for port but official wiki and forum says to use it. Why is that? 443 is still better overall, right?

443 is preferred since it's the default HTTPS port, making it less likely to be blocked by aggressive outbound network filtering. Using it generally results in somewhat higher traffic and quality for the client.

443 is preferred since it's the default HTTPS port, making it less likely to be blocked by aggressive outbound network filtering. Using it generally results in somewhat higher traffic and quality for the client.

Thank you. I will be testing various port to see which one has better result.

Has anyone ever experienced a sudden tank in hits? my 2-month old client on a vps was doing 30+ hits/minute when in a span of a week it dropped to about 21~

I did a full restart early on when I noticed the drop but unfortunately it didn't help. First time hosting hath client so no idea if this is just normal "dip"

EDIT: Seems back to "normal" hits for now (26~) though not as high as I initially had.. Hopefully it climbs back steadily soon

This post has been edited by kdeadz: Sep 7 2025, 04:23

At present, the proportion of IPv6 traffic at the entry point of China Mobile's core network is 66.16%, and the proportion of IPv6 traffic at the exit point of the core network is 71.91%. Moreover, the Cyberspace Administration of China and two other departments have issued the "Key Points for Further Promoting the Large-scale Deployment and Application of IPv6 by 2025". Data source: Chinese official

My quality has tanked I'm getting cache download fail
I'm using hath-rust I wonder if latest version has a problem or It's something in general
Help

under 2000 now so no hath

the log is filled with cache download fail starting from the 3rd september late in the day

This post has been edited by 918273: Sep 4 2025, 08:51

My quality has tanked I'm getting cache download fail
I'm using hath-rust I wonder if latest version has a problem or It's something in general
Help

under 2000 now so no hath

the log is filled with cache download fail starting from the 3rd september late in the day

You may want to check if there is a problem with your network connection to the image server, or you can try the proxy option to connect to the image server through a proxy.

james58899 It was running on latest version for multiple days without problems so not a problem with your program most likely
I don't know how to check the image server I mean I can browse the web so beyond that I don't know

I don't know how to check the image server I mean I can browse the web so beyond that I don't know

The error message contains the URL of the image server. You can try pinging the server or opening it in a browser.

The error message contains the URL of the image server. You can try pinging the server or opening it in a browser.

Hmm I have started full cache check so nothing there right now
actually It's going now for 4 hours and only 400/1227 static ranges I remember it taking 4 hours to finish on java version and yours being faster like 3 hours and that was before the static range changes that happened like a half a year ago I had over 1TB cache back then now It's only a little over 700 GB
EDIT I think a manual cache scan is much slower than a regular one so ignore the above

UPDATE so my client recovered fully quality 9300 but after the full cache scan there wasn't anything printed so cache was fine I guess actually I never had anything show up after scanning in all my years running the client just power outages forcing scans so I wonder was the problem on my side or server side hmm

This post has been edited by 918273: Sep 6 2025, 23:30

Hey, I was hoping you guys could help me understand the behavior of my H@H client.

About a year ago, I was running my H@H client off of a privacy VPN for port forwarding through the service PIA. This iteration of the client was located out of Vancouver Canada and had an average quality around 8000 with 400ish assigned static ranges. The cache is on a 2TB Sata SSD.

After experiencing one too many network interruptions (VPN caused) where the trust and quality nosedived, I ditched the VPN. The client now runs off of my ISP provided IP and port 443 in the United States. The quality sits around 9500 with nearly 100% uptime (power outages/Proxmox updating). It is assigned 70-80k KB/s upload speed, 2TB of cache space (18.61% used) and is around toplist space 500 for the past month.

My question is why isn’t the client getting assigned more static ranges? It has been at 644ish total ranges, with 255 HC, for the better part of a year. There has been some upward movement of the ranges towards P1 in the last year. But no new ranges have been assigned. I assumed when I relocated the client from Canada to the US and gave it twice the speed it would pick up ranges, but it seemingly hasn't. Are total static ranges an irrelevant metric to gauge client performance? Is this a result of the US being over-served by clients?

“The following ranges are currently assigned: P1 = 147, P2 = 149, P3 = 134, P4 = 214, HC = 255”

Thanks for reading this!

*(1.5-2 years ago the client had 6000 static ranges. However the SSD died, so I had to wipe the cache and start over. (IMG:[invalid] style_emoticons/default/cry.gif) )

There's no meaningful difference between US and CA as far as range assignments go. If it has plateaued, that's not an indictment against the client, it just means that there currently aren't any ranges available.

There's no meaningful difference between US and CA as far as range assignments go. If it has plateaued, that's not an indictment against the client, it just means that there currently aren't any ranges available.

I was curious if the CA to US shift had a major impact. I'm glad it didn't.

Thanks for the reply, and everything you do on the website!

My ISP switched me to a new ONT last Monday (and I did properly log off H@H before the switchover started) but only a couple of hours ago finally gave me a static IP address to deal with the being part of a CGNAT. So while I now have about triple the upload speed, has being off for nearly two weeks killed my client?

So while I now have about triple the upload speed, has being off for nearly two weeks killed my client?

Not really, but you could end up losing priority on some ranges that were reallocated to other clients while it was offline, depending on their relative score.

Thanks for your work

Not really, but you could end up losing priority on some ranges that were reallocated to other clients while it was offline, depending on their relative score.

This largely answers one question I have, but not a couple others.

Looking across Hentai@Home documentation, I don't think I've seen anything detailing best practices for turning it off, whether that's "I need to reboot for an update" (downtime in minutes), "I'm moving a thousand miles and the new ISP isn't ready yet" (downtime in days or weeks), "For reasons beyond the scope of a hypothetical, I have to pause my participation for five years" (downtime in years).

I'm running the client on a desktop and I've considered moving it, temporarily, to my laptop when I need to interrupt the desktop for hours at a time. However, it sounds like if I make an orderly shutdown, I shouldn't worry much about downtime on the scale of days. Is that correct?

My other questions:
Is moving the client software to another computer ill-advised? It looks like everything's well-contained in the HentaiAtHome_1.6.4 folder, so my idea was to shut the client down, move that folder, change router settings to forward the port to the laptop, and turn the client on there.
What is the situation if, for some contrived reason, I know I'm going to be unable to run the software for months or years, but I still want to maintain good relations and possibly return to it in the future?

Looking across Hentai@Home documentation, I don't think I've seen anything detailing best practices for turning it off, whether that's "I need to reboot for an update" (downtime in minutes), "I'm moving a thousand miles and the new ISP isn't ready yet" (downtime in days or weeks), "For reasons beyond the scope of a hypothetical, I have to pause my participation for five years" (downtime in years).

I'm running the client on a desktop and I've considered moving it, temporarily, to my laptop when I need to interrupt the desktop for hours at a time. However, it sounds like if I make an orderly shutdown, I shouldn't worry much about downtime on the scale of days. Is that correct?

If a client is down for more than three months, it's simply deleted, and clients with frequent downtime will become revoked sooner or later. But assuming that you're talking downtime to install updates or deal with hardware failures or system migrations etc...

In general, it's largely "incentive-aligned", meaning that keeping downtime to a minimum is both in the best interest of the system and in the best interest of each individual client. There is a range allocator script that's continuously sweeping through the ranges, assigning new ones or increasing the priority of existing range assignments if there are no online clients with P1 priority for that range in the region. So if your client is offline when the range allocator looks at a range it is assigned P1 for, it could be assigned to a different client.

Then, if there are two clients with a P1 for that range+region the next time it looks at it, it might decide to demote one of them. Which one it demotes largely comes down to how high each client is scoring compared to how many ranges it has.

It takes about five days to sweep through all the ranges, so it's pretty unlikely that it will hit your client during short downtimes, but the longer the downtime, the higher the chance.

(For HC ranges specifically, there is a cooldown of one day from a client goes offline until the range can be assigned to a different client. This is not the case for normal ranges, both for technical complexity reasons and because each HC range can only be assigned to one client per region, but that might be tweaked in the future.)

Is moving the client software to another computer ill-advised? It looks like everything's well-contained in the HentaiAtHome_1.6.4 folder, so my idea was to shut the client down, move that folder, change router settings to forward the port to the laptop, and turn the client on there.
What is the situation if, for some contrived reason, I know I'm going to be unable to run the software for months or years, but I still want to maintain good relations and possibly return to it in the future?

You can use something like rsync or robocopy to copy the cache over while the client is running to minimize downtime, then shut it down and do a second one to sync it up before starting it on the new system. But if the cache on the current client is full, it could somewhat underestimate its size until you do a full cache rescan on the new client. Which takes time, especially on a HDD.

Great, hope there will be an official docker version of h@h when 1.6.5 comes out

If a client is down for more than three months, it's simply deleted, and clients with frequent downtime will become revoked sooner or later. But assuming that you're talking downtime to install updates or deal with hardware failures or system migrations etc...

In general, it's largely "incentive-aligned", meaning that keeping downtime to a minimum is both in the best interest of the system and in the best interest of each individual client. There is a range allocator script that's continuously sweeping through the ranges, assigning new ones or increasing the priority of existing range assignments if there are no online clients with P1 priority for that range in the region. So if your client is offline when the range allocator looks at a range it is assigned P1 for, it could be assigned to a different client.

Then, if there are two clients with a P1 for that range+region the next time it looks at it, it might decide to demote one of them. Which one it demotes largely comes down to how high each client is scoring compared to how many ranges it has.

It takes about five days to sweep through all the ranges, so it's pretty unlikely that it will hit your client during short downtimes, but the longer the downtime, the higher the chance.

I'm looking at an impending one-month downtime (client is run on a laptop and will be carted around on an extended vacation) and assuming all my Trust and ranges will be razed to the ground in the process. About how long does it take to rebuild ranges for a 32 GB cache (client currently says I have about 24 utilized)?

Does the client run well enough on Android to mitigate this by migrating client + cache to an old phone and letting it run unmonitored over the course of the vacation? Home should see relatively mild weather after a comparably calm hurricane season, but a mothballed Samsung Galaxy S10 is the only thing in the house that wouldn't be instantly zonked if a thunderstorm came through and knocked out power for a few hours to a day. Oh never mind, I didn't realize Java support on mobile was in so bad a state.

This post has been edited by Andy Waltfeld: Oct 16 2025, 15:23

Does the client run well enough on Android to mitigate this by migrating client + cache to an old phone and letting it run unmonitored over the course of the vacation? Home should see relatively mild weather after a comparably calm hurricane season, but a mothballed Samsung Galaxy S10 is the only thing in the house that wouldn't be instantly zonked if a thunderstorm came through and knocked out power for a few hours to a day. Oh never mind, I didn't realize Java support on mobile was in so bad a state.

Technically, [github.com] hath-rust can run on Android, but since the Android system cannot guarantee that the program can run for a long time, I do not recommend using Android to run H@H.

If you want to run on a low-power device, the RPi5 is a good choice, as it has AES hardware acceleration.