[X] My Assistant

H@H 1.6.4 has been released. This is an optional update; see the first post for details.

Note that if your client has a cache from before September 2023, the first startup with this version can take some time, as it will prune any files from unassigned ranges from the cache.

stupid question

- If the filesize of a cached file does not match the expected size, we now ignore it and perform a backend fetch instead.

xpress16k compression doesn't have anything to do with this right?
I'm on windows 10

xpress16k compression doesn't have anything to do with this right?

No, those types of filesystem-level compression methods are transparent to applications. Though they also basically do nothing for image files except add overhead, so I wouldn't recommend using it.

^

True I know about already compressed files images videos archives whatev
just making sure I like to compress my storage drives from root a GUI for compress.exe already skips poorly compressed file types if I'm using it just wanted to check if something in cache were to be compressed would that make the client explode

but we're good (IMG:[invalid] style_emoticons/default/smile.gif)

my cache size is reduced by half after upgrading to 1.6.4
is this normal?

my cache size is reduced by half after upgrading to 1.6.4
is this normal?

p5 ranges got deleted I lost about 2 thirds of my cache

my cache size is reduced by half after upgrading to 1.6.4is this normal?

I guess most clients would see less of an effect, but it would have pruned unused files, so if your cache was from before Sep 2023 and it hasn't been butting against the disk limit, that's not abnormal.

The "official" test clients dropped by 5-10%, but those caches were all at the disk limit, so it would have already been gradually deleting them over time.

- If the cached number of static ranges is higher than the number of static ranges returned by the server during startup, we now force a cache rescan to prevent files in removed ranges from clogging up the cache.

can you also make this work in background? looks like it really takes very very very long times

Persistent cache data is not available

seems 164 breaks something,and still require force rescan even fallback to 163

can you also make this work in background? looks like it really takes very very very long times

Depends on the size of the cache and the speed of the storage device. It could take several hours for large caches on HDDs. Cache rescan is not designed to run in the background.

seems 164 breaks something,and still require force rescan even fallback to 163

If you stopped it before it could finish the startup, it can't store the persistent cache data since it hasn't been created yet.

CODE

[WARN] WARNING: There are 254 directories in the cache directory, but the server has only assigned us 84 static ranges.

Looks like I'm dropping by more than half (IMG:[invalid] style_emoticons/default/tongue.gif)
After hours of rebuilding the cache, it crashed at some point, when I started it up again:
(IMG:[files.catbox.moe] https://files.catbox.moe/n9v5ts.png)
Looks like I had nearly a 90% reduction! xD

Looks like I had nearly a 90% reduction! xD

I suppose that's possible when you have 200 GB of disk space and the speed is limited to 3 MB/s, but that's not a very typical setup. Not sure why it would take hours to rescan that cache though, unless it's on a networked drive.

I suppose that's possible when you have 200 GB of disk space and the speed is limited to 3 MB/s, but that's not a very typical setup. Not sure why it would take hours to rescan that cache though, unless it's on a networked drive.

It's a 6-year-old 7200RPM HDD running at 100% capacity, so idk, maybe just too old. The 3MB/s speed limit is because it's running on the computer I use for everything so I don't want to accidentally cause connection drops in games and such.
However it crashed again after only running for an hour with nothing in the logs to say why. Is there a verbose flag I can launch it with that might help me identify the cause?

EDIT:
I have figured it out, when I wake up my monitors from sleep it causes the program to crash. Reverting to 1.6.3 to see if it was a change on my end prior to updating this that caused it.

EDIT 2:
Yeah it's something with Windows, if I have the my screens off too long it does this stupid shuffle thing where it zooms in and out the screen to place the right screen on the right monitor (idk how to explain it better, but it's stupid shit happening with multimonitor setups) and if the GUI isn't minimized, it causes H@H (regardless of version) to crash. My guess something really dumb happened when I updated my JRE recently because it never use to crash from that.

This post has been edited by VampiricWulf: Dec 16 2024, 04:49

Good Morning. Unfortunately, I was out of town when the new enforcements for the version update were pushed, so my servers were shut out for a few days. I've since updated them to 1.6.4, but the trust has been stuck in the negatives, and I can't seem to regain and maintain positivity for them. I've had the servers verify the cache (28 hours to finish) so I am hoping the cache isn't the problem. What is the best way for me to troubleshoot this further?

Good Morning. Unfortunately, I was out of town when the new enforcements for the version update were pushed, so my servers were shut out for a few days. I've since updated them to 1.6.4, but the trust has been stuck in the negatives, and I can't seem to regain and maintain positivity for them. I've had the servers verify the cache (28 hours to finish) so I am hoping the cache isn't the problem. What is the best way for me to troubleshoot this further?

If they were running the outdated version right up until the hard cutoff and then remained offline for a while after, I guess it could be hard to get them going again, yeah. I made some tweaks to your clients that should allow them to catch up.

If they were running the outdated version right up until the hard cutoff and then remained offline for a while after, I guess it could be hard to get them going again, yeah. I made some tweaks to your clients that should allow them to catch up.

That seems to have resolved it. I appreciate the assistance. I honestly thought I had been running 1.6.3 this whole time, but I hadn't. I'll pay more attention to updates on this going forward.

I suppose that's possible when you have 200 GB of disk space and the speed is limited to 3 MB/s, but that's not a very typical setup. Not sure why it would take hours to rescan that cache though, unless it's on a networked drive.

I also had a reduction of a few terabytes. Had the full 6000 ranges under the old system and all allocated storage was full to the brim. Down to 469 regular + 158 HC now. Second client is similar but didn't have the full 6000 before, think it was ~4200.

H@H client ID: 49216
Question: Before December 1st (I don’t remember the exact date), the maximum speed of the H@H client was 40MB/s+. It's now 17015 KB/s and I want to get back to the previous maximum speed


Environment before and after maximum speed change:
1. The network environment has not changed. The client is located in CN. The ISP speed is 500Mb/s upstream and downstream. The actual speed measured by the speed test server using CN is up to 600Mb/s upstream and downstream. The router port is forwarded to the H@H client.
2. I reinstalled the operating system
Previously: Physical machine Windwos server 2022+ Hyper Windwos Server 2022, H@H runs on Hyper
Now: Physical machine Windwos server 2025+ Hyper Windwos Server 2025, H@H runs on Hyper


I tried the following after December 2024
1. Change the storage mode, physical machine PCIE3.0 SSD->smb->H@H to Hyper pass-through PCIE3.0 SSD->H@H. When verifying the cache, the SSD speeds before and after the change are: 10MB/s -> 160MB/s. Maximum speed is not restored.
2. Replace the H@H client and use hath-rust.1.8.0, but the maximum speed is not restored.
3. Upgrade the official H@H version, 1.6.3->1.6.4, the maximum speed is not restored
4. Replace Hyper with Windwos Server 2022 and use H@H.1.6.3 / H@H.1.6.4/hath-rust.1.8.0. The maximum speed is not restored.
5. Using H@H.1.6.4 this week, I saw more access error logs for [xxx.xxx.xxx.xx] http://xxx.xxx.xxx.xx/om/xxxxx from the error log, found several times that the GUI speed chart dropped from 16MB/s to 0.the --image-proxy related options are added to the startup command, and the maximum speed is not restored.
6.16 hours ago, I replaced port forwarding with nginx reverse proxy. 4 hours ago, I received a PM warning from Gallery System: H@H Client 49216 is unreachable, and the maximum speed has not been restored so far. What do I need to do, or can't I use a reverse proxy?
7. Forward the traffic port from the RPC server to H@H, and connections from other IPs go through the reverse proxy

When the H@H outgoing speed is stable at around 120Mb/s, before using the reverse proxy, the average number of connections displayed by the GUI is generally greater than 60, and after using it, the average number of connections is less than 10
NGINX distinguishes access paths in order to view requests other than image requests. As of now (about 2 hours) hath.network.8443.log/hath.network.8443.error.log has no content.

H@H log after using reverse proxy:

CODE

2024-12-21T08:33:41Z [info] {4695566/192.168.1.1}     Code=200 Bytes=672633   GET /h/28435c4408943d00a5a45cfc095a3bec80c3607d-672633-1280-1848-jpg/keystamp=1734770400-1ea33bc6fd;fileindex=130414005;xres=1280/002.jpg HTTP/1.1
2024-12-21T08:33:41Z [info] {4695567/192.168.1.1}     Code=200 Bytes=361490   GET /h/67ce10f1d721b9d4936dfa02018000ac2d8cba21-361490-1280-1810-wbp/keystamp=1734770400-e272f015e9;fileindex=168119317;xres=1280/0010_09.webp HTTP/1.1
2024-12-21T08:33:41Z [info] {4695566/192.168.1.1}     Code=200 Bytes=672633   Finished processing request in 0.01 seconds
2024-12-21T08:33:41Z [info] {4695567/192.168.1.1}     Code=200 Bytes=361490   Finished processing request in 0.00 seconds
2024-12-21T08:33:41Z [info] {4695568/192.168.1.1}     Code=200 Bytes=250550   GET /h/d74e3d6c7b3766c341562f66962b4efea9cf02c5-250550-1280-1807-wbp/keystamp=1734770400-9aacf3e8f0;fileindex=156558716;xres=1280/110.webp HTTP/1.1
2024-12-21T08:33:41Z [info] {4695570/192.168.1.1}     Code=200 Bytes=606831   GET /h/623d9c94a32f2783f747798b606ebf2ae7cece06-606831-1280-1760-jpg/keystamp=1734770400-a530f99563;fileindex=115419460;xres=1280/0014.jpg HTTP/1.1
2024-12-21T08:33:41Z [info] {4695569/192.168.1.1}     Code=200 Bytes=638428   GET /h/33b34645012db39c3f97b1cd2d53a1baf2d4f93f-638428-1280-1916-jpg/keystamp=1734770400-ca4bb13ed6;fileindex=119134552;xres=1280/004.jpg HTTP/1.1
2024-12-21T08:33:41Z [info] {4695568/192.168.1.1}     Code=200 Bytes=250550   Finished processing request in 0.00 seconds
2024-12-21T08:33:41Z [info] {4695569/192.168.1.1}     Code=200 Bytes=638428   Finished processing request in 0.00 seconds
2024-12-21T08:33:41Z [info] {4695570/192.168.1.1}     Code=200 Bytes=606831   Finished processing request in 0.01 seconds

Configuration currently in use:
H@H:

CODE

@start javaw -Xms256m -Xmx1024m -jar HentaiAtHomeGUI.jar --silentstart --port=8443 --disable-ip-origin-check --image-proxy-host=192.168.2.11 --image-proxy-type=http --image-proxy-port=7891

nginx:

CODE

server {
  listen 8443 ssl;
  listen [::]:8443 ssl;
  server_name *.xxx.hath.network;


  ssl_certificate      /certificate/hath.network.crt;
  ssl_certificate_key  /certificate/hath.network.key;
  ssl_session_cache shared:SSL:1m;
  ssl_session_timeout  10m;
  ssl_prefer_server_ciphers on;

  ssl_verify_client off;

  location /h {
    proxy_http_version 1.1;
    proxy_pass_header $http_host;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_set_header Range $http_range;
    proxy_set_header If-Range $http_if_range;
    proxy_send_timeout 5m;
    proxy_read_timeout 5m;
    #proxy_buffering off;
    proxy_pass https://192.168.1.29:8443;

    access_log off;
    #access_log /etc/nginx/log/hath.network.h.8443.log main;
    error_log /etc/nginx/log/hath.network.8443.error.log;
  }

  location / {
    proxy_http_version 1.1;
    proxy_pass_header $http_host;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_set_header Range $http_range;
    proxy_set_header If-Range $http_if_range;
    proxy_send_timeout 5m;
    proxy_read_timeout 5m;
    #proxy_buffering off;
    proxy_pass https://192.168.1.29:8443;

    #access_log off;
    access_log /etc/nginx/log/hath.network.8443.log main;
    error_log /etc/nginx/log/hath.network.8443.error.log;
  }
}

This post has been edited by _oTwTo_: Dec 21 2024, 11:41

Question: Before December 1st (I don’t remember the exact date), the maximum speed of the H@H client was 40MB/s+. It's now 17015 KB/s and I want to get back to the previous maximum speed

1. Change the storage mode, physical machine PCIE3.0 SSD->smb->H@H to Hyper pass-through PCIE3.0 SSD->H@H. When verifying the cache, the SSD speeds before and after the change are: 10MB/s -> 160MB/

If the storage was limited to 10 MB/s, that explains why the client was speed limited. It takes a while before that limit is lifted, so if you fixed it, it should go back soon. (I hurried it up a bit, though.)

If the storage was limited to 10 MB/s, that explains why the client was speed limited. It takes a while before that limit is lifted, so if you fixed it, it should go back soon. (I hurried it up a bit, though.)

This was changed at least two weeks ago and has not been restored yet, so I don't think that is the cause of the problem.

1. Assuming this is the problem, the image serving/test speed is about 10MB/s
2. The external speed of image service is 15MB/s, and the hard disk bookstore used is about 6MB/s.
3. I guess the speed test data should be generated in memory and should not involve disk speed.

Replenish:
When using BT, it can take up the entire 500Mb+ upload for a long time (2 days)

This post has been edited by _oTwTo_: Dec 21 2024, 12:23

3. I guess the speed test data should be generated in memory and should not involve disk speed.

The storage backend obviously needs to be fast enough to handle the requested image rate, otherwise your client will overload and be speed limited.

Incidentally, I looked a little closer and your client hasn't had a successful speedtest since yesterday, so you probably broke something.