[X] My Assistant

Has the idea of a h@h docker been explored?

I created this Docker image for my own personal use but for some reason it has been pulled 500K+ times now... It'll work on ARM based processors too. I try to keep it up to date using the latest H@H client. It is one of the few that actually lets you shutdown H@H cleanly when you stop the Docker container.

[hub.docker.com] https://hub.docker.com/r/frosty5689/hath/ta...ng=last_updated

This post has been edited by frozensnow: May 21 2021, 04:06

I created this Docker image for my own personal use but for some reason it has been pulled 500K+ times now... It'll work on ARM based processors too. I try to keep it up to date using the latest H@H client. It is one of the few that actually lets you shutdown H@H cleanly when you stop the Docker container.

[hub.docker.com] https://hub.docker.com/r/frosty5689/hath/ta...ng=last_updated

Looks pretty good.

I'd just argue that --net=host should be in the default way of the usage install. H@H does not do any UPnP or stuff and it is very easy to get your docker messed up with port configs. I think we already had people using this image asking for help where the they could not port forward (unsure whether it was this image because the bloke just gave up).

Getting this the past couple of days, h@h randomly dying

May 21 15:18:59 raspberrypi kernel: [670539.838483] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=4137,uid=0
May 21 15:18:59 raspberrypi kernel: [670539.838604] Out of memory: Killed process 4137 (java) total-vm:1204292kB, anon-rss:65160kB, file-rss:14404kB, shmem-rss:0kB, UID:0 pgtables:276kB oom_score_adj:0
May 21 15:18:59 raspberrypi kernel: [670539.958294] oom_reaper: reaped process 4137 (java), now anon-rss:0kB, file-rss:32kB, shmem-rss:0kB
May 21 15:18:59 raspberrypi systemd[1]: session-3605.scope: Succeeded.

PI 4 8GB RAM, 128GB SD card connected to an external drive (where h@h runs)

Getting this the past couple of days, h@h randomly dying

May 21 15:18:59 raspberrypi kernel: [670539.838483] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=4137,uid=0
May 21 15:18:59 raspberrypi kernel: [670539.838604] Out of memory: Killed process 4137 (java) total-vm:1204292kB, anon-rss:65160kB, file-rss:14404kB, shmem-rss:0kB, UID:0 pgtables:276kB oom_score_adj:0
May 21 15:18:59 raspberrypi kernel: [670539.958294] oom_reaper: reaped process 4137 (java), now anon-rss:0kB, file-rss:32kB, shmem-rss:0kB
May 21 15:18:59 raspberrypi systemd[1]: session-3605.scope: Succeeded.

PI 4 8GB RAM, 128GB SD card connected to an external drive (where h@h runs)

That's an out of memory after only 1.1GB use, way below the 8GBs.

Assuming that you are not continuously running something else on that pi to eat the memory you can increase the allocation to the JVM, e.g.

CODE

java -Xms4096m -Xmx6044m <H@H jar with your current args>

You can also check if ulimit -v has a value which may be limiting your memory per process (and reset with ulimit -v unlimited).

Getting this the past couple of days, h@h randomly dying

It's not "randomly dying", it's getting killed by the OS because it's running out of RAM. Incidentally, that's 1.2 GB of "virtual" memory size, it's only using about 80 MB real memory based on that readout. You'd have to find out what else is taking up all your memory.

With 1.61, on average how many gigs of files need to be downloaded before the number of static ranges increases from its current?

Looks pretty good.

I'd just argue that --net=host should be in the default way of the usage install. H@H does not do any UPnP or stuff and it is very easy to get your docker messed up with port configs. I think we already had people using this image asking for help where the they could not port forward (unsure whether it was this image because the bloke just gave up).

Yeah, I found it to be most consistent across different machines if you use --net=host, but it is not advocated as the first option unless you can't get bridge mode to work with the H@H port exposed. Simply because of the loss of security benefits from running it inside a Docker. I found bridge mode to work on my Unraid server, but not my Synology NAS. So there is something affecting it.

I have a trouble
Today I reboot my server as one of the storage device is dead. However, after the reboot, the Client cannot connect to the H@H server.

The status message is here:

2021-05-22T08:33:54Z [info] Hentai@Home 1.6.1 (Build 154) starting up
2021-05-22T08:33:54Z [info] Copyright © 2008-2020, E-Hentai.org - all rights reserved.
2021-05-22T08:33:54Z [info] This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v3 license.
2021-05-22T08:33:54Z [info] Loaded login settings from client_login
2021-05-22T08:33:54Z [info] Connecting to the Hentai@Home Server to register client with ID 26669...
2021-05-22T08:34:14Z [WARN] java.net.UnknownHostException: rpc.hentaiathome.net
2021-05-22T08:34:14Z [WARN] Retrying.. (2 tries left)
2021-05-22T08:34:14Z [WARN] java.net.UnknownHostException: rpc.hentaiathome.net
2021-05-22T08:34:14Z [WARN] Retrying.. (1 tries left)
2021-05-22T08:34:14Z [WARN] java.net.UnknownHostException: rpc.hentaiathome.net
2021-05-22T08:34:14Z [WARN] Retrying.. (0 tries left)
2021-05-22T08:34:14Z [WARN] Exhaused retries or aborted getting [rpc.hentaiathome.net] http://rpc.hentaiathome.net/15/rpc?clientb...act=server_stat
2021-05-22T08:34:14Z [ERROR] {hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:373)} Critical Error: Failed to get initial stat from server.
2021-05-22T08:34:14Z [info] Shutting down...
2021-05-22T08:34:14Z [info] Good-night
2021-05-22T08:34:14Z [info] Logging ended.


What is going on?

Seems this is a DNS problem, trying to fix it

This post has been edited by cb000: May 22 2021, 10:52

Nice One! Looking foward to future updates (IMG:[invalid] style_emoticons/default/biggrin.gif) (IMG:[invalid] style_emoticons/default/biggrin.gif)

Today my H@H crashed somehow.

Upon looking at the logs (without finding anything useful), I thought it would be good if there were some empty lines in log_err.old between the errors, because it's such an overfilled mess.

Another potential idea is that the error log would have a variable initialized on the launch time of H@H, then every time an error is written, a line is written saying how long it has been since the last error, and update the variable to the time of the latest error.
The file would no longer make you feel "argh this software is bugging nonstop from beginning to end" (because it's hard to notice differences in timestamp on each line).

Today my H@H crashed somehow.

If it shuts down without logging it to the error log, that means it died to some sort of OS/hardware event that prevented it from doing so. Usually that would be the out-of-memory killer or whatever the windows equivalent is, or possibly a JVM/hardware error. You would then usually find it in the OS error logs and/or a JVM error dump (hs_err_pid followed by the process id) in the H@H directory.

I found this in the hs_err something:

Thread 0x0000029b61e03800 Exception <a 'java/io/IOException'{0x00000004063d6300}> (0x00000004063d6300)
thrown [t:/workspace/open/src/hotspot/share/prims/jni.cpp, line 598]

After wandering around, I decided to try to add -Xint to the parameters of launch for next time. Of course, since the crash is far too much a random event, figuring if it worked, or made things a bit better even if it didn't fix everything, will be near-impossible. And I will wait until next crash or reason to restart H@H to start it like that.

Thread 0x0000029b61e03800 Exception <a 'java/io/IOException'{0x00000004063d6300}> (0x00000004063d6300)
thrown [t:/workspace/open/src/hotspot/share/prims/jni.cpp, line 598]

An IOException in the Hotspot JVM itself would usually indicate some sort of disk issue, so you might want to check the system logs for an entry about a failed disk read or something.

Nice to see this project is still going

Hi Tenboro, I'm getting this issue with invalid pathname, when the gallery contains invalid characters.

CODE

2021-10-21T03:24:02Z [info] GalleryDownloader: Starting download of gallery: meenfox-??A?10330
Exception in thread "Thread-16" 2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)} java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /root/torrents/gallery/meenfox-??A?10330 [2015215-1280x]/01_meenfox_A_1.jpg
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at sun.nio.fs.UnixPath.encode(UnixPath.java:147)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at java.io.File.toPath(File.java:2236)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at hath.base.GalleryDownloader$GalleryFile.download(GalleryDownloader.java:377)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at hath.base.GalleryDownloader.run(GalleryDownloader.java:91)
2021-10-21T03:24:02Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:749)}     at java.lang.Thread.run(Thread.java:748)

Link to the gallery (NSFW): https://e-hentai.org/g/2015215/8d6cb4fd5f/
H@H version: 1.6.0 Stable
Client ID: 29981
OS: Ubuntu
Java Version: openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-8u275-b01-0ubuntu1~18.04-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)

Is there anyway to clear the download queue? I tried to restart H@H but it still try to download the same gallery.

Edit: Checked the source code, seems like it's trying to call RPCServerHost to get the queue and gallery meta from server. Can I somehow clear it from client (IMG:[invalid] style_emoticons/default/sad.gif)?

This post has been edited by conanak99: Oct 21 2021, 05:57

Hi Tenboro, I'm getting this issue with invalid pathname, when the gallery contains invalid characters.

Is there anyway to clear the download queue? I tried to restart H@H but it still try to download the same gallery.

Edit: Checked the source code, seems like it's trying to call RPCServerHost to get the queue and gallery meta from server. Can I somehow clear it from client (IMG:[invalid] style_emoticons/default/sad.gif)?

The reason is your system/shell isn't configured to support unicode. I cleared your download queue, but you should probably check your OS docs to fix that if you want to use the downloader.

The reason is your system/shell isn't configured to support unicode. I cleared your download queue, but you should probably check your OS docs to fix that if you want to use the downloader.

Thank you, it works now.

To anyone with the same issue, you will need to add `set -x LC_ALL en_US.UTF-8` before running H@H.
It should solve all Unicode problems.

This post has been edited by conanak99: Oct 21 2021, 12:09

I decided to try to add -Xint to the parameters of launch for next time.

Finally got to try that, but it caused my temperatures graph to get lots of spikes (though the "current value" would be somewhat normal), so I took it off. A little random crash once in a while is less serious than being constantly oppressed by such a graph (IMG:[invalid] style_emoticons/default/tongue.gif)

Win 10 tried to nuke my RAID 1 array, with H@H on it, after my windows region changed.

After changing the region back, almost all my data was recoverable, but Windows is considering the whole Core_Old directory as corrupt.

Is there any way to fix that? or replace it? or am I going to have to re-start H@H from zero?

After changing the region back, almost all my data was recoverable, but Windows is considering the whole Core_Old directory as corrupt.

Is there any way to fix that? or replace it? or am I going to have to re-start H@H from zero?

Hard to say. You could try to reset the file permissions on the entire directory tree from the File Explorer, then start H@H with --verify-cache (or check "Verify cache integrity on next startup" from the settings page), but YMMV as far as how many files are usable.