[X] My Assistant

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.

Since switching to the reverse proxy in 18 hours, I have also found that there have been no requests with the path /t, only /h, so I changed the nginx configuration to distinguish requests a few hours ago.

Since switching to the reverse proxy in 18 hours, I have also found that there have been no requests with the path /t, only /h, so I changed the nginx configuration to distinguish requests a few hours ago.

We don't really support reverse proxy setups, but the latest failed test was 14 minutes after that post, so it's probably still broken.

We don't really support reverse proxy setups, but the latest failed test was 14 minutes after that post, so it's probably still broken.

It has been changed to direct port forwarding, let’s see how it works.


update:
2024-12-21T11:41:03Z Completed a test, the maximum speed increased, 17015->17291

This post has been edited by _oTwTo_: Dec 21 2024, 13:57

Hello Tenboro,
My H@H client is encountering a serious issue where it keeps falling into a login error loop. I’ve tried resetting the client key, but that didn’t resolve the problem.

I noticed the topic https://forums.e-hentai.org/index.php?showtopic=281857 that may help me solve the problem.

This post has been edited by pixia12345: Dec 21 2024, 16:45

are there any plans to upgrade to http/3? it offers significant performance upgrades over http/1.1

are there any plans to upgrade to http/3? it offers significant performance upgrades over http/1.1

Not really, no. Outside of the complexity involved, going to HTTP/2 or /3 doesn't really make much of a difference for a single file request, and /3 in particular would also require people to open UDP in addition to TCP.

Oh geez, they're already up to HTTP3. HTTP2 still feels like "that new thing" but I guess it's been almost a decade. UDP though... Oh that's gonna be fun with all the work firewall issues...

If I understand it right, most of the problems HTTP3 (and HTTP2) aim to solve are caused by - or at least exacerbated by - large volumes of tiny connections in parallel. I'm going to go out on a limb and assume that most of this site's network traffic ends up dominated by large, single, serialized transfers.

And for that matter, many of those single transfers are to different H@H nodes anyway, meaning they couldn't take advantage of the new shiny features of HTTP2/3 even if they wanted to. Maybe the main servers could, but what would that really help out with? Serving thumbnails, maybe? But even then, many thumbnails seem to be ganged together nowadays in multi-image chunks anyway, once again pushing into "large single serialized" territory.

also,china firewall/isp loves qos UDP traffic,so http/3 is a nerf

Updated to 1.6.4 recently and noticed that my current static ranges has been 839 for a few days. I currently have 1TB cache set aside for this as well as 30MB/sec upload. I assume this will eventually add more ranges at some point?

I also noticed this.
Went from 3580 with 1.6.3 down to 266 with 1.6.4.
Cache drive had roughly 130 GB cache content removed.

I also noticed this.
Went from 3580 with 1.6.3 down to 266 with 1.6.4.
Cache drive had roughly 130 GB cache content removed.

They were removed server-side some time ago as you can see earlier in this thread, 1.6.4 just forces a rescan to get rid of removed ranges.

- 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.

I'll keep an eye on how (and if) the assigned ranges will increase again over time.
Dutch connection.... so that might take a while. (IMG:[invalid] style_emoticons/default/mellow.gif)

My client's (46851) quality has decided to suddenly drop from ~7500-8500 to 350 and is continuing to drop. I have no idea how or why it would suddenly do this and it is not recovering. Any thoughts?

I noticed that when the gallery name is too long, the download completes successfully, but an error still occurs. Please refer to the log below for details.

CODE

2025-01-03T02:12:02Z [ERR] {java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)} java.io.IOException: Could not create directory /volume1/rawdata_local/hentai_at_home/download/[にゅう工房] 化けてよ！！ポン子ちゃん！！EX 近所の化けだぬきのお姉ちゃんの弱みを握ってフィギュアとかソシャゲキャラとか好きな子とかに変身してもら
ってそのままエッチしまくっちゃう話！！ [中国翻訳] [3150850]; check permissions and I/O errors.
2025-01-03T02:12:02Z [ERR] {java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)}     at hath.base.Tools.checkAndCreateDir(Tools.java:48)
2025-01-03T02:12:02Z [ERR] {java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)}     at hath.base.GalleryDownloader.initializeNewGalleryMeta(GalleryDownloader.java:273)
2025-01-03T02:12:02Z [ERR] {java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)}     at hath.base.GalleryDownloader.run(GalleryDownloader.java:60)
2025-01-03T02:12:02Z [ERR] {java.base/java.lang.Throwable$WrappedPrintStream.println(Throwable.java:785)}     at java.base/java.lang.Thread.run(Thread.java:1583)
2025-01-03T02:12:02Z [WARN] GalleryDownloader: Could not create gallery download directory "[にゅう工房] 化けてよ！！ポン子ちゃん！！EX 近所の化けだぬきのお姉ちゃんの弱みを握ってフィギュアとかソシャゲキャラとか好きな子とかに変身してもら
ってそのままエッチしまくっちゃう話！！ [中国翻訳] [3150850]". Your filesystem may not support Unicode. Attempting fallback.

CODE

username@hostname:[path]/3150850$ ls
01_EX_000.png  06_EX_004.png  11_EX_009.png  16_EX_014.png  21_EX_019.png  26_EX_024.png  31_2.jpg
02_EX_000.png  07_EX_005.png  12_EX_010.png  17_EX_015.png  22_EX_020.png  27_EX_025.png  galleryinfo.txt
03_EX_001.png  08_EX_006.png  13_EX_011.png  18_EX_016.png  23_EX_021.png  28_EX_026.png
04_EX_002.png  09_EX_007.png  14_EX_012.png  19_EX_017.png  24_EX_022.png  29_EX_027.png
05_EX_003.png  10_EX_008.png  15_EX_013.png  20_EX_018.png  25_EX_023.png  30_EX_028.png

my H@H client's quality is dropping for no reason? Nothing wrong with the internet, i have everything set up perfect and there are no errors in the client either?

I noticed that when the gallery name is too long, the download completes successfully, but an error still occurs. Please refer to the log below for details.

CODE

2025-01-03T02:12:02Z [WARN] GalleryDownloader: Could not create gallery download directory "[にゅう工房] 化けてよ！！ポン子ちゃん！！EX 近所の化けだぬきのお姉ちゃんの弱みを握ってフィギュアとかソシャゲキャラとか好きな子とかに変身してもら
ってそのままエッチしまくっちゃう話！！ [中国翻訳] [3150850]". Your filesystem may not support Unicode. Attempting fallback.

Looks like it's working as intended. Different filesystems have different length limits, and especially when unicode is involved it's hard to cut off in a way that works on all filesystems, so it falls back to not using the gallery name in the folder if it fails. Non-FDE LUKS is limited to only ~63 unicode characters, for example.

my H@H client's quality is dropping for no reason? Nothing wrong with the internet, i have everything set up perfect and there are no errors in the client either?

Usually means there are ISP/regional issues.

Looks like it's working as intended. Different filesystems have different length limits, and especially when unicode is involved it's hard to cut off in a way that works on all filesystems, so it falls back to not using the gallery name in the folder if it fails. Non-FDE LUKS is limited to only ~63 unicode characters, for example.
Usually means there are ISP/regional issues.

If this phenomenon does not violate the original expectations, I think the log level "ERR" should be changed to "WARN".
Additionally, I find the "check permissions" part somewhat strange, as the directory name has already been replaced with the GID at this point.

This post has been edited by Celtae: Jan 3 2025, 13:58

I was change my ISP at January 4, and when I rerun my H@H(34060) client,there are a lot of WARN logs like this:

CODE

2025-01-09T16:06:15Z [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.
2025-01-09T16:06:16Z [WARN] Request host did not send Content-Length, aborting transfer. (sun.net.www.protocol.http.HttpURLConnection:http://xxx.xxx.xxx.xxx/om/165556853/89ebc9b4b29b8719479ba2b124939f30d8319093-5205957-2111-3020-jpg/8ad129ba207a45a65f6f39acd7291c7a99c229b6-792700-1280-1831-wbp/1280/4rfkqn6gto1wge1jvtc/hathrequest-34060)

Open port is 34060, same as client ID. Received files count is less than 100 even the running time is over 200 hours. And the GalleryDownloader is abnormal too (only few images can be downloaded (IMG:[invalid] style_emoticons/default/anime_cry.gif) ). The Trust/Quality data seems normally now.
I have noticed that the WARN log url is http url, and it can't be accessed in browser too. But it can be accessed when I change http:// to https://.

I was change my ISP at January 4, and when I rerun my H@H(34060) client,there are a lot of WARN logs like this:

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.

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.

(IMG:[invalid] style_emoticons/default/anime_cry.gif) Chinese ISP always block IPs by strange reasons...It is possible to using HTTPS for image requests?