[X] My Assistant

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.

Thanks for the answer. I was too impatient. (IMG:[invalid] style_emoticons/default/smile.gif)

My ISP pulled the plug on me, they limited my upload in early March and then asked me to sign a bullying agreement to no longer use upload, which I refused them. Then just now they just choked off my internet, but they are still charging($1.2 per day). Looks like I'm going to have to leave the program.


F**k you, China Telecom.

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

I have decided to just move my client to my Mac instead of trying again and again to stay inside the VM, no more CPU problem (for real this time) after few days of operation, and of course the quality is still swinging back and forth, I wrote a small script to record the value every minute and made a graph out of it.

(IMG:[i.imgur.com] https://i.imgur.com/FX0i24z.png)

I think it might be internet problem, but I still don't understand why it always happens on midnight.
The log is filled with these errors regardless of time, not sure if they are related.

CODE

2025-03-19T11:51:35Z [info] {1509272/103.181.1.54}    Code=200 Bytes=83124    Finished processing request in 0.13 seconds (620.33 KB/s)
2025-03-19T11:51:35Z [debug] {1509273/183.225.159.250} The connection was interrupted or closed by the remote host.
2025-03-19T11:51:35Z [debug] Remote host terminated the handshake
2025-03-19T11:51:35Z [debug] {1509246/49.228.113.42}   The connection was interrupted or closed by the remote host.
2025-03-19T11:51:35Z [debug] Read timed out
2025-03-19T11:51:35Z [debug] {1509247/49.228.113.42}   The connection was interrupted or closed by the remote host.
2025-03-19T11:51:35Z [debug] Read timed out
2025-03-19T11:51:35Z [debug] {1509270/203.75.191.236}  Code=200 Bytes=5728646  The connection was interrupted or closed by the remote host.
2025-03-19T11:51:35Z [debug] Broken pipe
2025-03-19T11:51:35Z [info] {1509276/27.51.49.157}    Code=200 Bytes=311522   GET /h/128f1fde75b2cceb42a26c3d28f322ccd4407f38-311522-1280-1816-wbp/keystamp=1742385600-56508794aa;fileindex=179484535;xres=1280/i_128.webp HTTP/1.1
2025-03-19T11:51:35Z [info] {1509276/27.51.49.157}    Code=200 Bytes=311522   Finished processing request in 0.06 seconds (5106.92 KB/s)
2025-03-19T11:51:35Z [info] {1509274/18.140.197.11}   Code=200 Bytes=43112    GET /h/d0e4f85fd64bd1ca3c9f23e606948b623decfe06-43112-1280-720-wbp/keystamp=1742385600-fe77b4326d;fileindex=129195745;xres=1280/11_102.webp HTTP/1.1
2025-03-19T11:51:35Z [info] {1509274/18.140.197.11}   Code=200 Bytes=43112    Finished processing request in 0.04 seconds (1026.48 KB/s)
2025-03-19T11:51:35Z [info] {1509275/183.225.159.250} Code=200 Bytes=7139837  GET /h/d2760ba178b7329cc8eda6f3e001f8f986cc8028-7139837-540-720-gif/keystamp=1742385600-df29a20e06;fileindex=167727746;xres=org/caesar_2of6.gif HTTP/1.1
2025-03-19T11:51:35Z [debug] {1509198/112.20.125.102}  Code=200 Bytes=6570089  The connection was interrupted or closed by the remote host.
2025-03-19T11:51:35Z [debug] Broken pipe
2025-03-19T11:51:35Z [info] {1509277/182.239.90.31}   Code=200 Bytes=41732    GET /h/5156247b15ca5074d586875f9a1bd8df92463699-41732-1280-720-wbp/keystamp=1742385600-75077ba023;fileindex=157007243;xres=1280/1.4_194.webp HTTP/1.1
2025-03-19T11:51:35Z [info] {1509277/182.239.90.31}   Code=200 Bytes=41732    Finished processing request in 0.03 seconds (1490.43 KB/s)
2025-03-19T11:51:36Z [debug] {1509279/111.32.69.234}   The connection was interrupted or closed by the remote host.
2025-03-19T11:51:36Z [debug] Remote host terminated the handshake
2025-03-19T11:51:37Z [debug] Main thread starting cycle at startTime=1742385097316
2025-03-19T11:51:37Z [debug] Main thread sleeping with lastThreadTime=22 sleeptime=9978, memory total=49152KiB free=37788KiB max=4194304KiB
2025-03-19T11:51:37Z [info] {1509280/175.108.246.24}  Code=200 Bytes=96222    GET /h/f90ebb15736a7c2c05d6001433a8a454a403f307-96222-1280-1969-wbp/keystamp=1742385600-b24633a0ea;fileindex=174826412;xres=1280/0012.webp HTTP/1.1
2025-03-19T11:51:37Z [info] {1509280/175.108.246.24}  Code=200 Bytes=96222    Finished processing request in 0.09 seconds (1118.86 KB/s)
2025-03-19T11:51:37Z [debug] {1509281/106.6.143.143}   The connection was interrupted or closed by the remote host.
2025-03-19T11:51:37Z [debug] Remote host terminated the handshake
2025-03-19T11:51:38Z [debug] {1509252/112.49.109.23}   Code=200 Bytes=1114312  The connection was interrupted or closed by the remote host.
2025-03-19T11:51:38Z [debug] Broken pipe
2025-03-19T11:51:38Z [info] {1509282/106.6.143.143}   Code=200 Bytes=7599444  GET /h/645c1548a65ec468330e9de0a3d079fc5a7ce67b-7599444-594-334-gif/keystamp=1742385600-1929594de9;fileindex=177511348;xres=org/bGhWxuSDy5s0Zx_3_13of13.gif HTTP/1.1
2025-03-19T11:51:38Z [info] {1509283/138.199.22.144}  Code=200 Bytes=123702   GET /h/f3cf95e4a99dd739faa0bb6a0f6a4ce4d5400854-123702-1280-1780-jpg/keystamp=1742385600-849a8fdf76;fileindex=179514629;xres=org/3.jpg HTTP/1.1
2025-03-19T11:51:39Z [info] {1509283/138.199.22.144}  Code=200 Bytes=123702   Finished processing request in 0.18 seconds (672.29 KB/s)
2025-03-19T11:51:39Z [debug] {1509284/183.95.251.83}   The connection was interrupted or closed by the remote host.
2025-03-19T11:51:39Z [debug] Remote host terminated the handshake
2025-03-19T11:51:39Z [debug] Connecting to 212.7.202.50...
2025-03-19T11:51:39Z [info] {1509286/183.95.251.83}   Code=200 Bytes=4806654  GET /h/9a8917b345c14a2fa8490cb8027e4aa2ae26273d-4806654-1500-1500-gif/keystamp=1742385600-1bf319d717;fileindex=178317388;xres=org/cms44Videl_vC2rw_c1_1500.gif HTTP/1.1
2025-03-19T11:51:39Z [debug] {1509288/120.84.9.47}     The connection was interrupted or closed by the remote host.
2025-03-19T11:51:39Z [debug] Remote host terminated the handshake
2025-03-19T11:51:39Z [debug] {1509290/153.151.231.55}  The connection was interrupted or closed by the remote host.
2025-03-19T11:51:39Z [debug] Remote host terminated the handshake

I'm curious if the client speed measurement was changed in 1.6.4 patch? Because my client's measured speeds dropped quite drastically after the 1.6.4 update with no other changes in my setup. Don't know if that has any impact on client performance, though, as the measured speeds are still over 10000kBps, but they used to be about 2-3x higher before the update. Thanks!

This post has been edited by ruokasooda1: Mar 26 2025, 18:48

I think it might be internet problem, but I still don't understand why it always happens on midnight.

On the assumption you have general Internet issues, there's monitoring tools like [www.paessler.com] PRTG (or a PingPlotter trial) so you don't have to collect data manually...but troubleshooting is probably getting offtopic for H@H thread.

Kinda looks like you might be running into a rolling 24-hour cap or throttle though.

Suggestion:
Can't we just have the client downloads distributed as precompiled Graalvm native image? Or maybe an option alongside the standard jar.

It makes the client portable and smaller overall as it eliminates the need for JVM installation. It's also more performant and consume less cpu and memory.

Ive been using running my client for years as native image without any downsides or issues.

This post has been edited by rozos: Apr 21 2025, 11:36

Suggestion:
Can't we just have the client downloads distributed as precompiled Graalvm native image? Or maybe an option alongside the standard jar.

It makes the client portable and smaller overall as it eliminates the need for JVM installation. It's also more performant and consume less cpu and memory.

Ive been using running my client for years as native image without any downsides or issues.

You might want to try the client rewritten in Rust. [github.com] https://github.com/james58899/hath-rust

You might want to try the client rewritten in Rust.

This looks very interesting, thank you! But why are there no plans to add bandwidth limiting?

You might want to try the client rewritten in Rust. [github.com] https://github.com/james58899/hath-rust

Look great. Have you done any benchmark to see how it compare against graalvm image in term of CPU usage?

My machine have practically bottomless ram but its CPU is quite limited.

This looks very interesting, thank you! But why are there no plans to add bandwidth limiting?

Implementing bandwidth limiting is complex and can reduce performance.
Bandwidth is already limited by RPC, using client bandwidth limit is not very useful.

Look great. Have you done any benchmark to see how it compare against graalvm image in term of CPU usage?

My machine have practically bottomless ram but its CPU is quite limited.

I don't have comparison data, but it should be much lower CPU usage.
Some feedback said the speed test was twice as high.

Implementing bandwidth limiting is complex and can reduce performance.
Bandwidth is already limited by RPC, using client bandwidth limit is not very useful.
I don't have comparison data, but it should be much lower CPU usage.
Some feedback said the speed test was twice as high.

I tried giving it a shot but it refuse to execute.

CODE

bash: ./hath-rust-aarch64-unknown-linux-gnu: cannot execute binary file: Exec format error

Tried both glibc version in tumbleweed (glibc 2.41) and musl in Oracle Enterprise Linux 8.9. B
Both setup returning the same error.

Any idea what's going on?

Ok nvm I was retarded and downloaded the aarch64 version because my muscle memory assumes the first in list should always be x86

This post has been edited by rozos: Apr 24 2025, 16:42

Is there a Linux docker image for H@H?

Is there a Linux docker image for H@H?

You can find it on Docker Hub [hub.docker.com] here.

Or try the Rust version [github.com] here.

Nice

Thank you for you

Hello there,
I've been running multiple H@H clients for years without issues, but in the last month Spamhaus has flagged two of my IP addresses on their Botnet Controller List, accusing them of C2 activity (win.cobalt_strike), which is a clear false positive. I'm running clients on multiple cloud service providers using port 443.

Is anyone else experiencing similar issues? Thank you.

I've been running multiple H@H clients for years without issues, but in the last month Spamhaus has flagged two of my IP addresses on their Botnet Controller List, accusing them of C2 activity (win.cobalt_strike), which is a clear false positive. I'm running clients on multiple cloud service providers using port 443.

Is anyone else experiencing similar issues? Thank you.

We had one other guy reporting something similar recently. They were taken off the list after contacting them, and they are still running it on the same IP. You just have to tell them it's a false positive since it's a legitimate P2P CDN, and to fuck off with making false accusations.

Hard to say if it's based on prior suspicious activity from the IP in question, or if something is just fundamentally broken with their detection, but it looks like that other guy had only been running on that IP for a little over a month.

Good work! Thank you for your contribution.

Thanks for your work

Okay, so I've had my H@H server running on version 1.6.1 for the better part of four years uninterrupted. I realised a mandatory update dropped in December of last year, but I quite literally missed the memo till I decided to manually check if my client was running this evening. which directed me to come to the forums, and what do you know, there was the warning in my pm box that my server was offline, my question is, can I really not reapply for H@H as the warning says? i realise it was an oversight on my part but it really was a genuine error.