[X] My Assistant

Did some testing and found out H@H is incompatible with Little Snitch on MacOS version 11.7.2.
Will not serve files (but everything else works fine and the quality actually won't drop) after around 8 hours.

Was working 2-3 years ago I remember running it with H@H on my MBP before I got my RPI, but I guess now they switched to the new Apple API after MacOS forced them to and something broke.

Originally thought it was my router's dual WAN feature causing the problem but had the same problem today on my single WAN China Telecom line with my iMac at a different physical location.

This post has been edited by Based Brandon: Jan 22 2023, 20:23

I can't find an answer to this question anywhere, no FAQ or anything.

How much CPU power does H@H need? Can I run this with 1 core, 2 thread at 2.8ghz? I'm trying to run this in a VM. Will be using about 1.1tb of SSD storage space.

How much CPU power does H@H need? Can I run this with 1 core, 2 thread at 2.8ghz? I'm trying to run this in a VM. Will be using about 1.1tb of SSD storage space.

Should be plenty. Actual CPU requirements depend almost entirely on much traffic it gets. H@H can run on just about anything that runs Java, but very high-traffic clients might get CPU-starved if it's on the anemic end.

Found out few months ago some of my H@H download not complete, always missing 1-2 image to complete the whole gallery download, I found out that because it didn't create a TXT file after download complete

When I check the log, it have :

[WARN] Request host did not send Content-Length, aborting transfer. (sun.net.www.protocol.https.DelegateHttpsURLConnection:https://
[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.
[WARN] java.net.SocketException: Invalid or missing Content-Length
[WARN] java.io.IOException: Server returned HTTP response code: 403 for URL: http://...
[WARN] Exhaused retries or aborted getting http://...
[WARN] GalleryDownloader: Permanently failed downloading gallery:
[WARN] java.net.SocketTimeoutException: Read timed out
[WARN] javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message

Because not all gallery have this issue, only gallery with large no. of image, like 100+ will have 1-2 image missing. but it happen more and more now,

I didn't change any setting of H@H and my firewall, only update Java to latest version, Is there any setting I can tell it to retry more before fail, or retry and missing image only so I don't need to check the TXT and click on the link to re-download all image again? Thanks

This post has been edited by tongkai: Jan 23 2023, 11:39

I can't find an answer to this question anywhere, no FAQ or anything.

How much CPU power does H@H need? Can I run this with 1 core, 2 thread at 2.8ghz? I'm trying to run this in a VM. Will be using about 1.1tb of SSD storage space.

My RPI4 can handle around 10MBps when overclocked to 2Ghz (4 cores) with OpenJDK 11 if that means anything. Desktop/server CPU should do better.

Uses around 40% CPU (of 1 core) on Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz x4 when serving 100Mbps (small B here) of files

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/01/24/bin4o.png)

This post has been edited by Based Brandon: Jan 24 2023, 06:58

Just come back to report my H@H issue is because 185.177.126.251 has been blocked by reported as Malicious Websites, after whitelist HTTP to it, it back to normal

Found out few months ago some of my H@H download not complete, always missing 1-2 image to complete the whole gallery download, I found out that because it didn't create a TXT file after download complete

When I check the log, it have :

[WARN] Request host did not send Content-Length, aborting transfer. (sun.net.www.protocol.https.DelegateHttpsURLConnection:https://
[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.
[WARN] java.net.SocketException: Invalid or missing Content-Length
[WARN] java.io.IOException: Server returned HTTP response code: 403 for URL: http://...
[WARN] Exhaused retries or aborted getting http://...
[WARN] GalleryDownloader: Permanently failed downloading gallery:
[WARN] java.net.SocketTimeoutException: Read timed out
[WARN] javax.net.ssl.SSLProtocolException: Received fatal alert: unexpected_message

Because not all gallery have this issue, only gallery with large no. of image, like 100+ will have 1-2 image missing. but it happen more and more now,

I didn't change any setting of H@H and my firewall, only update Java to latest version, Is there any setting I can tell it to retry more before fail, or retry and missing image only so I don't need to check the TXT and click on the link to re-download all image again? Thanks

Is it possible to run this as downloader / client-mode only?, tried to look in wiki no avail, and the downloader seems deprecated

I have one client, was using it with dedicated server but for now it's no more. I needed the download function until i can find a server replacement to host it
---
edit: i also want to know if it's possible to make the *.jar selecting certain network interface (such as using eth2 instead of eth0), so i can make sure it will use which network interface

This post has been edited by psionicdecimator: Feb 8 2023, 21:48

Is it possible to run this as downloader / client-mode only?, tried to look in wiki no avail, and the downloader seems deprecated

No.

edit: i also want to know if it's possible to make the *.jar selecting certain network interface (such as using eth2 instead of eth0), so i can make sure it will use which network interface

Not natively, but you could use iptables to route it to a particular interface.

Last week I have to poweroff my Raspberry Pi ubuntu server for maintenance.
After the maintenance, when I Power On the RPi, I cannot use the H@H anymore. It shows the following error.

CODE

[WARN] Startup Failure: FAIL_CONNECT_TEST:Failed to connect to *.*.hath.network port 443: No route to host

After some testing, I find that the port was closed in the RPi firewall. I should have enabled it in past as I could use H@H before the maintenance. I don't know why it is closed. To reopen it, use the firewall-cmd

CODE

firewall-cmd --add-port=443/tcp --permanent && firewall-cmd --reload

Hope it will help you in solving the problem.

This post has been edited by cb000: Feb 13 2023, 07:41

Last week I have to poweroff my Raspberry Pi ubuntu server for maintenance.
After the maintenance, when I Power On the RPi, I cannot use the H@H anymore. It shows the following error.

CODE

[WARN] Startup Failure: FAIL_CONNECT_TEST:Failed to connect to *.*.hath.network port 443: No route to host

After some testing, I find that the port was closed in the RPi firewall. I should have enabled it in past as I could use H@H before the maintenance. I don't know why it is closed. To reopen it, use the firewall-cmd

CODE

firewall-cmd --add-port=443/tcp --permanent && firewall-cmd --reload

Hope it will help you in solving the problem.

Updating Ubuntu between major versions seems to turn the firewall back on. I updated my VPS from 18 to 22 and the same thing happened.

Recently, I migrated the SSD where HatH is located from my old laptop to a 2U server and noticed that the CPU was spiking up every 10 seconds.
Upload speed often drops sharply when CPU spikes occur.
I have never paid attention to the CPU usage of old laptop before. So are these CONSISTENT CPU SPIKES a problem? Is my hardware / software broken? (IMG:[invalid] style_emoticons/default/sad.gif)
What happens when the spike occurs?

All cache files of HatH are on the 500G WD Blue SATA SSD
unraid version: 6.11.5
docker repository: [hub.docker.com] https://hub.docker.com/r/frosty5689/hath
Use /mnt/disk1 instead of /mnt/user for all HatH paths (/hath/cache, /hath/tmp etc.) (avoid FUSE overhead).
HatH container log has been disabled, and network type is Host.

Apologize for any mistakes in English grammar.

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XARab.jpeg)

normal:

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAgAa.jpeg)

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XA6zU.jpeg)

SPIKES:

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAeZL.jpeg)

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAzOp.jpeg)

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAFav.jpeg)

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAd03.jpeg)

hath settings:

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/19/XAmkq.md.jpeg)

This post has been edited by pl0okm: Feb 18 2023, 21:48

Recently, I migrated the SSD where HatH is located from my old laptop to a 2U server and noticed that the CPU was spiking up every 10 seconds.
Upload speed often drops sharply when CPU spikes occur.

I think it is JVM GC, client will call System.gc() every 10s.
You can turn on the thread name in the htop settings, and it should show what thread is using the CPU.

I think it is JVM GC, client will call System.gc() every 10s.
You can turn on the thread name in the htop settings, and it should show what thread is using the CPU.

I turned on "Show custom thread names" and clicked F10 to save it, but all threads of HatH still show the process name, it is no different from the images above.

https://e-hentai.org/hentaiathome.php
"if you have a headless server that cannot run SpeedTest"

This is a bit out of date. There are now [www.speedtest.net] Speedtest CLI binaries and also a [github.com] Python version so it should be possible to run & get the results image link on most any headless server.

Here's what I thought, might be wrong but might give you an idea on what's wrong:
CPU spiking every 10s's not normal. I have not observed anything like that on any of my clients (Mac/PC/RaspberryPi/VPS)
H@H shouldn't use that much CPU unless something's wrong. So maybe try checking your Java installation/settings. I'd recommend updating/reinstalling the newest version of OpenJDK and run H@H off that.

Another thing I'd say (I don't have definitive proof for this) is I noticed your network traffic spikes up at the same time the CPU spikes before coming back down.
Might be 1. someone's spamming requests at you, happened to me a couple of times, didn't cause huge CPU spikes but did seem to made my Trust go down for some reason, I just changed the ports and seemed to went away.
2. your internet can't handle that much traffic, so the traffic is jammed on your server. I noticed with my machines whenever I reach full bandwidth utilization the CPU utilization goes up significantly as well.
So try setting a lower speed on H@H might solve that problem (server won't be trying to hit a speed it can't.) Your server might TEST (burst) very high but the ISP/hosting might throttle any sustained connection causing the problem.

Just noticed you use Docker, I don't so... Might be a Docker problem, I'd have no idea on that.
I'd try just running it without Docker but with JDK/JRE

EDIT:
I actually do have some proof about the Internet/CPU stuff.
(IMG:[s2.loli.net] https://s2.loli.net/2023/02/24/eGKpsOHukEv3zoT.png)
(IMG:[s2.loli.net] https://s2.loli.net/2023/02/24/ANnPrO8TvkWjqtX.png)

Left part of both img (Internet/CPU) was before I upgraded the connection and the right part is after.
As you can see even though the traffic went up (as it got assigned more static ranges over time,) the CPU utilization actually decreased after the upgrade.

This post has been edited by Based Brandon: Feb 24 2023, 13:24

was waiting for this

Thanks guys!
I switched to [hub.docker.com] akinokaede/hentaiathome docker image with jre 18.0.1 and everything is OK now. (IMG:[invalid] style_emoticons/default/smile.gif)
After 34 hours, CPU usage is stable at 30% ~ 40%. "Show custom thread names" also works and the VM thread will have a cpu small "spike" ( only 8% ~ 18% ) every 8 to 10 seconds.

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/27/EuKoZ.jpeg)

(IMG:[i.328888.xyz] https://i.328888.xyz/2023/02/27/EuJR8.jpeg)

how hard would it be to 'enable' IPv6 support for E-Hentai and the H@H client?
With IPv6 adoption around 40% ([www.google.com] according to google), I would suggest that, if the work for enabling dual stack H@H is not already ongoing, it should be started soon

Something is wrong with my H@H client. The website is showing the max speed as being extremely low, but it is regularly fulfilling pull requests well above that speed.
EDIT: Trust is maxed out, so I have no idea what the issue is.

This post has been edited by Granberia HK Fire: Jun 15 2023, 21:22

Can HTTP keepalive be enabled on PRC and the image server?

In regions with high latency between the client and servers, the TCP handshake takes a lot of time. Enabling keepalive has the potential to reduce latency by half and allows TCP congestion control to better utilize bandwidth.
This may increase server load and require client updates, I'm not sure if it's worth it, but I believe it can significantly reduce response times when cache misses.

In addition, enabling TLS1.3 on the client also reduces the connection time between the browser and the client.