[X] My Assistant

Unless your client was revoked before you stopped running it, sure.

Hi I've gotten my PC issues sorted as far as I can tell and wanted to get back up and running but my client has been revoked?

Sorry if I went about this the wrong way do I wait or what?

Sounds like the server was blocked by your ISP or upstream. You can try looking into using a proxy for image requests, see the notes for 1.6.3.

I just write a simple Python proxy progarm. It will covert HTTP request from H@H client to HTTPS (ignore cert error) and response content to H@H client in HTTP method. Seems GalleryDownloader and other HTTP GET request is work fine if H@H client connect through this progarm. Is it OK to using this proxy program? (IMG:[invalid] style_emoticons/default/blink.gif)

I just write a simple Python proxy progarm. It will covert HTTP request from H@H client to HTTPS (ignore cert error) and response content to H@H client in HTTP method. Seems GalleryDownloader and other HTTP GET request is work fine if H@H client connect through this progarm. Is it OK to using this proxy program? (IMG:[invalid] style_emoticons/default/blink.gif)

If it works, it works.

I am upgrading hardware. Should I copy across the existing cache from the old machine to the new one or just reset my cache and start again?

This post has been edited by MyAltTitle: Jan 13 2025, 06:07

I am upgrading hardware. Should I copy across the existing cache from the old machine to the new one or just reset my cache and start again?

Always copy it if possible.

I'm wondering the feasibility of backing up the cache in case of disk failure, as far as i know the cache has to match whatever the server knows about the client, there will be trust issue of course, but is that better than starting from scratch? How old of a backup should become unusable?

I'm wondering the feasibility of backing up the cache in case of disk failure, as far as i know the cache has to match whatever the server knows about the client, there will be trust issue of course, but is that better than starting from scratch? How old of a backup should become unusable?

Well, it's definitely feasible. If the backup is newer than three days it should be fine. If it's older it would cause trust issues relative to how much older, but it's hard to say exactly what the cutoff would be for it to still be usable.

As long as you rescan the cache (which would be automatic if it didn't shut down properly), there shouldn't be any desync issues.

For those interested in what an H@H client might look like with H2, H3, OCSP, HSTS, etag/if-modified-since/range requests and keep alive support (but not actually implementing most of those in the actual client code), [gitlab.com] I've built a docker image that bundles all that into an easy to configure package. It does it by terminating everything at an Nginx reverse proxy + a couple client mods to make that more efficient.

I didn't save the stats, but almost a year back on a client with max ranges and at a larger relative share of the network, I recall that I used to used to see ~30% of requests coming in with H3. Now I'm "down" to ~17% with ~4700 ranges. The majority of everything else is served over H2 since TLS allows H2 discovery using ALPN. Though there's still a surprising amount of H1 (~10%).
If you're wondering how a request could possibly end up using H3, it's repeat clients that have been previously informed that H3 is available on this server.


This is all based on [gitlab.com] an existing project of mine that I'd posted about a while back for better reverse proxy support. It adds to the H@H client:
- Http keepalive support (so the reverse proxy doesn't need to reconnect for every request)
- reinstates support for unencrypted connections (because the the proxy is handling encryption)
- A certificate passthrough mechanism
- Cached file service offload to nginx. All request still go to the H@H client, but it can return a file path to serve, instead of the actual file.
- Java21 and a Native-image binay build (so no need for a JRE install)

All of these should be implemented in a backwards compatible way, enabled using command line arguments. However, if certain features are turned on, then some existing features get disabled. Mainly bandwidth/connection/flood limits. Arguably, OS or nginx features could be used to better implement those, but I haven't cared enough to look into them.

Hello Tenboro, could you give me some information about my client 43894.
The quality is around 0 to 4000 since a month. Before, it was almost always above 9000. Could you see why ? Is my ISP doing weird stuff ?
I also upgraded the operating system (windows 11 23h2 to 11 24h2), and upgraded the client from 1.6.3 to 1.6.4; could those have an impact on quality ?

This post has been edited by m0t: Jan 18 2025, 17:38

For those interested in what an H@H client might look like with H2, H3, OCSP, HSTS, etag/if-modified-since/range requests and keep alive support (but not actually implementing most of those in the actual client code), [gitlab.com] I've built a docker image that bundles all that into an easy to configure package. It does it by terminating everything at an Nginx reverse proxy + a couple client mods to make that more efficient.

I didn't save the stats, but almost a year back on a client with max ranges and at a larger relative share of the network, I recall that I used to used to see ~30% of requests coming in with H3. Now I'm "down" to ~17% with ~4700 ranges. The majority of everything else is served over H2 since TLS allows H2 discovery using ALPN. Though there's still a surprising amount of H1 (~10%).
If you're wondering how a request could possibly end up using H3, it's repeat clients that have been previously informed that H3 is available on this server.
This is all based on [gitlab.com] an existing project of mine that I'd posted about a while back for better reverse proxy support. It adds to the H@H client:
- Http keepalive support (so the reverse proxy doesn't need to reconnect for every request)
- reinstates support for unencrypted connections (because the the proxy is handling encryption)
- A certificate passthrough mechanism
- Cached file service offload to nginx. All request still go to the H@H client, but it can return a file path to serve, instead of the actual file.
- Java21 and a Native-image binay build (so no need for a JRE install)

All of these should be implemented in a backwards compatible way, enabled using command line arguments. However, if certain features are turned on, then some existing features get disabled. Mainly bandwidth/connection/flood limits. Arguably, OS or nginx features could be used to better implement those, but I haven't cared enough to look into them.

so your hah client can read X-Real-IP sent from nginx?
i have a some extreme small spec servers that use as proxy only,I am finding a way to use them to run h@h.now I can use some proxy software+ nginx reserve proxy to do that,but the problem is,original h@h only read IP from socket(this is what AI told me),so I can't get actual user IP from h@h logs.this is important because I am running grafana that read from h@h logs to show top 10 countries(ip)

Hi,

I’m looking for advice on how to clean up excess cache data for my H@H setup. Here’s my situation:

Client version: 1.6.4
Environment: Running on Docker in a Synology NAS
Cache setup: I have a dedicated SSD for caching with a maximum disk cache size of 800GB configured for the client.
However, my Synology currently shows that the cache folder has grown to 854GB. I suspect the extra data might have been generated when I previously migrated the cache folder between two Synology NAS units using a sync tool (Cloud Sync).

Is there a reliable way to identify and clean up this excess data without affecting the proper functioning of H@H?

Any suggestions would be greatly appreciated. Thanks in advance!

Hello Tenboro, could you give me some information about my client 43894.
The quality is around 0 to 4000 since a month. Before, it was almost always above 9000. Could you see why ? Is my ISP doing weird stuff ?
I also upgraded the operating system (windows 11 23h2 to 11 24h2), and upgraded the client from 1.6.3 to 1.6.4; could those have an impact on quality ?

Your client has periods of high failure rates. It's hard to say what the cause is, but if the system isn't noticeably struggling, it's most likely an ISP issue.

I’m looking for advice on how to clean up excess cache data for my H@H setup. Here’s my situation:

Client version: 1.6.4
Environment: Running on Docker in a Synology NAS
Cache setup: I have a dedicated SSD for caching with a maximum disk cache size of 800GB configured for the client.
However, my Synology currently shows that the cache folder has grown to 854GB. I suspect the extra data might have been generated when I previously migrated the cache folder between two Synology NAS units using a sync tool (Cloud Sync).

Is there a reliable way to identify and clean up this excess data without affecting the proper functioning of H@H?

Any suggestions would be greatly appreciated. Thanks in advance!

If you migrated the cache while running it, your cache state is most likely desynced from the actual cache. To fix it, you can either start the client with --rescan-cache, or delete the pcache files from the data directory after shutting it down.

Your client has periods of high failure rates. It's hard to say what the cause is, but if the system isn't noticeably struggling, it's most likely an ISP issue.
If you migrated the cache while running it, your cache state is most likely desynced from the actual cache. To fix it, you can either start the client with --rescan-cache, or delete the pcache files from the data directory after shutting it down.

Thank you!!!

Your client has periods of high failure rates. It's hard to say what the cause is, but if the system isn't noticeably struggling, it's most likely an ISP issue.

Thanks. The system hasn't changed, and it's dedicated to H@H. It's an ISP issue, can't do much about it. I'll leave it running as is, hoping that ISP sorts itself.

Well, it's definitely feasible. If the backup is newer than three days it should be fine. If it's older it would cause trust issues relative to how much older, but it's hard to say exactly what the cutoff would be for it to still be usable.

As long as you rescan the cache (which would be automatic if it didn't shut down properly), there shouldn't be any desync issues.

Great, I should do it sometime, recently moved my client to a better machine and virtualised it, much more easy to backup than before.

I've noticed over the last few days that my P1 ranges are slowly being demoted to P4 ranges. Is this a normal occurrence at times?

I've noticed over the last few days that my P1 ranges are slowly being demoted to P4 ranges. Is this a normal occurrence at times?

Depends on the region. For the secondary regions it's not unusual since it only uses P1 and P4 ranges, and usually means a client that had the range previously came back online after being offline for a short-ish period.

Should I be running a VPN with this? I'm worried about getting flagged by my ISP

Upgrading to 1.6.4 removed ~2/3 of my static ranges. Maybe they were stale, but since then my client hasn't gained any new static ranges either. Is this expected? The client is in a high coverage region (Europe).

Upgrading to 1.6.4 removed ~2/3 of my static ranges. Maybe they were stale, but since then my client hasn't gained any new static ranges either. Is this expected? The client is in a high coverage region (Europe).

Upgrading does not remove ranges, it just prunes the cache for ranges that aren't actually assigned to your client.

If any ranges are freed up in your region, they are assigned to the client that scores the highest on capability divided by number of ranges assigned, so if you aren't assigned any new ones, that either means there are other clients that score higher or no ranges are being freed. And like you say, Europe is pretty oversaturated.