[X] My Assistant

This is on a very low-resource machine, but I figured it'd throw an error if there was a memory problem. Not even all RAM is being taken so that shouldn't be an issue. Using jamvm instead of regular java due to the resource stortage(s).

If it is a very low resource machine H"H could hit the swap, and that would make things super slow.

You're checking memory usage with free right? It shall display swap usage too.

Also, if it is a machine with little memory H@H has the --use-less-memory switch. You shall try that if you didn't try it yet.

If it is a very low resource machine H"H could hit the swap, and that would make things super slow.

You're checking memory usage with free right? It shall display swap usage too.

Also, if it is a machine with little memory H@H has the --use-less-memory switch. You shall try that if you didn't try it yet.

I made sure to try those before coming to the forum! So yeah, no luck with them. (i.e. the switch didn't help and the swap usage and ram usage is not even close to high.

Any other ideas?

The log_err is empty and log_out says this:

CODE

*********************************************************
2015-10-07T16:13:10Z Logging started
2015-10-07T16:13:10Z [info] Started logging to data/log_err
2015-10-07T16:13:10Z [info] Hentai@Home 1.2.5 starting up
2015-10-07T16:13:10Z [info]
2015-10-07T16:13:10Z [info] Copyright (c) 2008-2014, E-Hentai.org - all rights reserved.
2015-10-07T16:13:10Z [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.
2015-10-07T16:13:10Z [info]
2015-10-07T16:13:10Z [debug] Setting altered: use_less_memory=true
2015-10-07T16:13:10Z [info] Loaded login settings from client_login
2015-10-07T16:13:10Z [info] Connecting to the Hentai@Home Server to register client with ID 2640...
2015-10-07T16:13:10Z [info] Connecting to rpc.hentaiathome.net...
2015-10-07T16:13:10Z [debug] Connected to http://rpc.hentaiathome.net/clientapi.php?clientbuild=96&act=server_stat
2015-10-07T16:13:10Z [debug] Received contentLength=74
2015-10-07T16:13

Any other ideas?

Try strace (install it if you do not have it straight away). It shall wrap the H@H command, e.g. strace jamvm -jar HentaiAtHome.jar --use-less-memory

strace prints out all system calls, if jamvm freezes it is very probable that is freezes on some system call. If it is some simple system call like open then the problem is likely to be some permission, if it is an internal system call like mmap then jamvm is kind off screwed.

Common simple calls (I/O calls): open, close fstat, read, write
Common internal calls (memory management): mmap, munmap. brk, mprotect

NOTE: do **not** post the entire strace output here, strace can output very sensitive info about your machine. If in doubt post the last 10-20 lines.

EDIT (NOTE 2): I assume is a Linux based machine

This post has been edited by blue penguin: Oct 7 2015, 18:38

If it is a very low resource machine H"H could hit the swap, and that would make things super slow.

You're checking memory usage with free right? It shall display swap usage too.

Also, if it is a machine with little memory H@H has the --use-less-memory switch. You shall try that if you didn't try it yet.

There are worse things than swapping. Such as a machine with <=128MB of RAM, swap being not an option as it wears out flash memory, and the H@H failing to even start all threads due to being out of memory.

And even with the "low memory mode", H@H is still a memory hog in a lot of other locations. Min. 70-80MB of free memory required, or it WILL swap/crash during operation. Safe value would be around 128MB free RAM.

Besides, that log is incomplete which is expected. The log doesn't get flushed until the client is killed. So there are probably 1-2 lines missing. That goes for both log files.

I have ~92MB of free memory and swap has about 900MB free.

Strace+program output:

CODE

rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
brk(0xaf0000)                           = 0xaf0000
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x757a8000
mprotect(0x757a8000, 4096, PROT_NONE)   = 0
clone(child_stack=0x759a70d0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x759a7588, tls=0x759ae960, child_tidptr=0x759a7588) = 28385
futex(0x44c6ec, FUTEX_WAIT_PRIVATE, 7, NULL) = 0
futex(0x44c718, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x44c718, FUTEX_WAKE_PRIVATE, 1)  = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1], NULL, 16) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], NULL, 16) = 0
futex(0x44c6a4, FUTEX_WAIT_PRIVATE, 1, NULL2015-10-07T21:15:31Z [info] Started logging to data/log_out
2015-10-07T21:15:31Z [info] Started logging to data/log_err
2015-10-07T21:15:31Z [info] Hentai@Home 1.2.5 starting up
2015-10-07T21:15:31Z [info]
2015-10-07T21:15:31Z [info] Copyright (c) 2008-2014, E-Hentai.org - all rights reserved.
2015-10-07T21:15:31Z [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.
2015-10-07T21:15:31Z [info]
2015-10-07T21:15:31Z [info] Loaded login settings from client_login
2015-10-07T21:15:31Z [info] Connecting to the Hentai@Home Server to register client with ID 2640...
2015-10-07T21:15:31Z [info] Connecting to rpc.hentaiathome.net...
2015-10-07T21:15:32Z [info] /clientapi.php?clientbuild=96&act=server_stat: Retrieving 74 bytes...

Also when I run this on my PC where I normally run it, the output looks a little bit different (and it works there of course):

CODE

2015-10-07T21:24:59Z [info] Started logging to data/log_err
2015-10-07T21:25:01Z [info] Hentai@Home 1.2.5 starting up
2015-10-07T21:25:01Z [info]
2015-10-07T21:25:01Z [info] Copyright (c) 2008-2014, E-Hentai.org - all rights reserved.
2015-10-07T21:25:01Z [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.
2015-10-07T21:25:01Z [info]
2015-10-07T21:25:01Z [debug] Setting altered: disable_bwm=true
2015-10-07T21:25:01Z [info] Loaded login settings from client_login
2015-10-07T21:25:01Z [info] Connecting to the Hentai@Home Server to register client with ID 2640...
2015-10-07T21:25:01Z [info] Connecting to rpc.hentaiathome.net...
2015-10-07T21:25:01Z [debug] Connected to http://rpc.hentaiathome.net/clientapi.php?clientbuild=96&act=server_stat
2015-10-07T21:25:02Z [debug] Received contentLength=66
2015-10-07T21:25:02Z [info] /clientapi.php?clientbuild=96&act=server_stat: Retrieving 66 bytes...
2015-10-07T21:25:02Z [debug] Finished. bytecounter=66
2015-10-07T21:25:02Z [debug] Received response: OK
2015-10-07T21:25:02Z [debug]
2015-10-07T21:25:02Z [debug] min_client_build=88
2015-10-07T21:25:02Z [debug] cur_client_build=96
2015-10-07T21:25:02Z [debug] server_time=1444253094
2015-10-07T21:25:02Z [debug] Setting altered: min_client_build=88
2015-10-07T21:25:02Z [debug] Setting altered: cur_client_build=96
2015-10-07T21:25:02Z [debug] Setting altered: serverTimeDelta=-8
2015-10-07T21:25:02Z [info] Reading Hentai@Home client settings from server

(bla bla regular server boot)

Why is one of my clients getting 66 bytes and the other 74? One is a linux machine yeah, but is that the difference?

This post has been edited by Vulpix: Oct 7 2015, 23:30

That 74/66 difference is odd. Counting the bytes in the actual response I get 66 bytes.

But the server announces 74 bytes. And the H@H client will stall unless it receives as many bytes as announced.

I just tried against all 3 rpc servers. They are all exaggerating by 8 bytes. All of them are reporting 74 bytes, but are only sending 66.

I have no clue why your second client got an appropriate response.



EDIT:
Found the issue. Some Java versions may unexpectedly specify "Accept-Encoding: gzip".
The server will respond with "Content-Encoding: gzip" and add 8 bytes onto "Content-Length" which screws the integrity check. The client isn't handling this correctly.

Summary: Use a different Java environment until the client is made compatible with yours.

This post has been edited by foobar20324: Oct 8 2015, 00:45

foobar is certainly right, that "futex(0x44c6a4, FUTEX_WAIT_PRIVATE, 1, NULL" is waiting to read something from a file identifier an not getting it.

Another way to getting around it might be to hack the H@H client itself and explicitly add .setRequestProperty("Accept-Encoding", "gzip");. I'm on a machine that does not have the H@H source and am not running H@H myself either, therefore i do not promise that it will work. But it is worth a try.

Another way to getting around it might be to hack the H@H client itself and explicitly add .setRequestProperty("Accept-Encoding", "gzip");. I'm on a machine that does not have the H@H source and am not running H@H myself either, therefore i do not promise that it will work. But it is worth a try.

No, that will NOT work. .setRequestProperty("Accept-Encoding", "identity"); is what needs to be added. And while at it, best add it both to GalleryFileDownloader and FileDownloader.

Found the issue. Some Java versions may unexpectedly specify "Accept-Encoding: gzip".
The server will respond with "Content-Encoding: gzip" and add 8 bytes onto "Content-Length" which screws the integrity check. The client isn't handling this correctly.

Hmm, good catch. While clients setting Accept-Encoding: gzip looks like a bug undocumented feature in some versions of Java, the server isn't supposed to honor that, compression should be disabled on the RPC servers. Which it obviously wasn't, after this functionality was moved to new servers back in August. The configuration has been corrected now.

@Vulpix: Try again now.

It works now! Thanks to y'all for helping me find the issue and to tenboro for fixing it up (IMG:[invalid] style_emoticons/default/smile.gif)

Finally, I have realized my dream of running H@H on my router (TP-Link Archer C7) (IMG:[invalid] style_emoticons/default/biggrin.gif) 128MB RAM (~100M free). USB disk connected via the USB port. All good, all running in jamvm on OpenWRT ChaosCalmer 15.05.

2015-10-09T10:08:25Z [info] {22/213.87.157.71} Code=200 Bytes=86428 Finished processing request in 0.02 seconds (4321.40 KB/s)
2015-10-09T10:08:30Z [info] {23/213.87.157.71} Code=400 Bytes=28 Finished processing request in 0.00 seconds (28.00 KB/s)
2015-10-09T10:08:59Z [info] {24/85.242.70.129} Code=200 Bytes=698317 GET /h/881ac234ceee9ddc954339627022598be8871ccc-698317-1085-1600-png/keystamp=1444385700-cfe0bda87a/142.png HTTP/1.1
2015-10-09T10:09:00Z [info] {24/85.242.70.129} Code=200 Bytes=698317 Finished processing request in 0.55 seconds (1260.50 KB/s)
2015-10-09T10:09:01Z [info] {25/86.202.193.193} Code=200 Bytes=113024 GET /h/0930bcc7fe5c57fd1d4cf06cc563b51d6f183896-113024-550-712-gif/keystamp=1444385700-361630cdbe/6.gif HTTP/1.1
2015-10-09T10:09:01Z [info] {25/86.202.193.193} Code=200 Bytes=113024 Finished processing request in 0.03 seconds (3424.97 KB/s)
2015-10-09T10:09:02Z [info] {26/81.25.53.100} Code=200 Bytes=29490 GET /h/e4e353996930f413b7a9d0b08f9dd2281d86066d-29490-1200-750-jpg/keystamp=1444385700-887b9ce805/000_00.jpg HTTP/1.1
2015-10-09T10:09:02Z [info] {26/81.25.53.100} Code=200 Bytes=29490 Finished processing request in 0.01 seconds (3686.25 KB/s)
2015-10-09T10:09:03Z [info] {28/89.65.101.174} Code=200 Bytes=469128 GET /h/93df42ab1938c71670a312dda7feea085338635f-469128-1200-1744-jpg/keystamp=1444385700-fd08c18835/img014.jpg HTTP/1.1
2015-10-09T10:09:04Z [info] {28/89.65.101.174} Code=200 Bytes=469128 Finished processing request in 0.42 seconds (1106.43 KB/s)


This post has been edited by Vulpix: Oct 9 2015, 12:09

Thanks for the update!

Thx for the update!

I just started H@H, and my client has been running for 14h.
However there're a few issues I want to ask here:

- My average speed as shown is only around 11.94KB/s sent, and 5.57KB received. I'm in NA, with about 30Mb/s up and down, how does this happen ? When I check the log some of the down/upload are spike up to 750KB/s, but most are only <100. Did I mess up somewhere ? There's no beautiful line on my chart, only painful looking spikes.

- My cache fills really slow. I was expecting a few GB after the 1st 12h, seeing I put 200GB for cache. Anything I can do manually to speed up the process ?

- If the issues above are because of the huge cover and low demand in North and South America, should I switch to Adopt-A-Server or rent and setup a H@H server somewhere in Asia for better demand (and better hath gain) ?

I just started H@H, and my client has been running for 14h.

That's quite normal, don't worry. It takes a couple weeks at least for the cache to start growing to a good size and for the client to start serving files closer to peak capacity.

I just started H@H, and my client has been running for 14h.
However there're a few issues I want to ask here:

- My average speed as shown is only around 11.94KB/s sent, and 5.57KB received. I'm in NA, with about 30Mb/s up and down, how does this happen ? When I check the log some of the down/upload are spike up to 750KB/s, but most are only <100. Did I mess up somewhere ? There's no beautiful line on my chart, only painful looking spikes.

- My cache fills really slow. I was expecting a few GB after the 1st 12h, seeing I put 200GB for cache. Anything I can do manually to speed up the process ?

- If the issues above are because of the huge cover and low demand in North and South America, should I switch to Adopt-A-Server or rent and setup a H@H server somewhere in Asia for better demand (and better hath gain) ?

Welcome to the weird H@H local server world. I'll try to help you a bit.
If you want to fill your cache faster just use H@H download links. When client downloads whole galleries it also adds every downloaded image to cache permanently. Also use your server's IP as your personal H@H proxy. You change this option here: https://e-hentai.org/uconfig.php
Now about spikes. After almost a month of running H@H this is how my client usually looks at 1PM: [i.imgur.com] http://i.imgur.com/TePd1SQ.jpg I never get smooth line, it's always spiky. But I got steady 1000 trust and 7000-9300 quality so everything is fine. My connection is pretty slow [1250 KB/s = 1MB/s] so atm I have 15,3 hitrate and 5,05 hathrate. But everything is stable so I'm not complaining.

This post has been edited by cichy133: Oct 17 2015, 12:07

One of my H@H clients has a problem.
It run normally until this morning.
The message "Startup notification failed." shows up again and again when I try to run it.

I have checked the port usage.
It is not used by other programs.

The following is the message in the packet:

CODE

FAIL_CONNECT_TEST:Failure when receiving data from the peer
There was even going to be a party for you. A big party that all your friends were invited to. I invited your best friend the companion cube. Of course, he couldn't come because you murdered him. All your other friends couldn't come either because you don't have any other friends because of how unlikable you are. It says so here in your personnel file: Unlikable. Liked by no one. A bitter, unlikable loner whose passing shall not be mourned. SHALL. NOT. BE. MOURNED. That's exactly what it says. Very formal. Very official. It also says you're adopted, so that's funny too.

It runs on Ubuntu with a static IP.
What kind of problem may it be?
And what actions should I take to fix it?

----------------------------------------------------------------------------------------------------

It finally works again!
But still don't know what happened.


This post has been edited by w45451212: Oct 19 2015, 11:05

People need to stop spreading this misinformation. Tenboro has stated that H@H prioritizes based on static ranges for which the client has been assigned. Thus, using the downloader and proxy only fill your cache with files that your client may not have priority to serve.

Welcome to the weird H@H local server world. I'll try to help you a bit.
If you want to fill your cache faster just use H@H download links. When client downloads whole galleries it also adds every downloaded image to cache permanently. Also use your server's IP as your personal H@H proxy.

People need to stop spreading this misinformation. Tenboro has stated that H@H prioritizes based on static ranges for which the client has been assigned. Thus, using the downloader and proxy only fill your cache with files that your client may not have priority to serve.

Well I never said these files have priority. He just wanted to know the best way to fast cache collection. But I personally experienced pretty high usage of my previously downloaded images, so it does work just fine.
But obviously patience is the most important thing.

Quick question.

how .hathdl work ?

I have put the hathdl files on hathdl folder.

but its already 1 hour, no single files downloaded....

Just wait.