[X] My Assistant

I'm not seeing anything unusual or slow with that log. If you are talking about downloads being slow for *you*, that's a problem with Firefox 51, not H@H.

1.4.1 already works around the brokenness of Firefox 51 by quickly telling it to sod off with invalid requests and request the file the proper way. It will still be slower than a working browser, but not by more than half a second or so. At this point, about 65% of clients have updated.

I have been on Cyberfox 50.1.0 so I have not had that problem. I have the Hentai@Home Local Network Host set the way I always ran it as 127.0.0.1:2002 and when I use to download files it would not charge GP or not say it was. Now with the changes it shows GP being used which is fine I have over 60K GP. But I notice that when I am viewing the images using multiviewer the pages load about maybe 5 or 6 than stalls.. and I have to wait for it to continue before I can read anymore. There use to be a reload button for the page when you had a stuck page but even that is missed. So now I have to sit and wait until it decides to load more pages. Very slow to read a doujin now.

I have been on Cyberfox 50.1.0 so I have not had that problem. I have the Hentai@Home Local Network Host set the way I always ran it as 127.0.0.1:2002 and when I use to download files it would not charge GP or not say it was. Now with the changes it shows GP being used which is fine I have over 60K GP. But I notice that when I am viewing the images using multiviewer the pages load about maybe 5 or 6 than stalls.. and I have to wait for it to continue before I can read anymore. There use to be a reload button for the page when you had a stuck page but even that is missed. So now I have to sit and wait until it decides to load more pages. Very slow to read a doujin now.

It doesn't load images through your local client IP anymore unless that client happens to be picked for the request. There's a 500ms delay between each request, so unless you mean "very slow" as "I scroll very fast and only two images load per second" then that's the problem.

I don't understand the H@H proxy mechanism...

my H@H cliant local IP:port set in "Hentai@Home Local Network Host".
and I use chrome browser.

In my multi-page viewer, img tag coded in html as shown below.
(X is any number or character)

CODE

<img id="imgsrc_X" src="http:// not local IP /XXXX / XXX.jpg >

"src" property is not local IP.( Even if reload.)

Is this something wrong?
Is this a malfunction?


By the way, is there a browser that supports the following clause?

Some browser configurations prevent external web sites from accessing URLs with local network IPs, the site must then be whitelisted for this to work.

I don't understand the H@H proxy mechanism...

The proxy mechanism has been removed a while ago. It simply no longer exists.

"Hentai@Home Local Network Host" means something entirely different, that's ONLY for miss-configured firewalls which deny you to access your forwarded ports by your public IP. Which is only relevant, if you happen to be chosen *by chance* as eligible to serve a file to your own location.

Which is only relevant, if you happen to be chosen *by chance* as eligible to serve a file to your own location.

I understanded now!
thank you!

seems like the client no longer loads images if ur using fire fox thats the problem

what i meant was :
client no longer proxy from above posts (seems like the client no longer loads images)

an if your using firefox that's the problem with slow loading

what i meant was :
client no longer proxy from above posts (seems like the client no longer loads images)

an if your using firefox that's the problem with slow loading

And we still have no clue what you are trying to say though.

* H@H proxy does not exist for several months now
* FF 51 is completely broken
* these two things above are completely unrelated

And we still have no clue what you are trying to say though.

* H@H proxy does not exist for several months now
* FF 51 is completely broken
* these two things above are completely unrelated

t_T yeah i give up my sad excuse of explanation i wanted to correct my self but -.- my English isn't that grate

sorry and thanks for help

I just updated to 1.4.1 from 1.4.0 and i now have a -100 trust is this normal ? or is there an issue with me dedi box?

I just updated to 1.4.1 from 1.4.0 and i now have a -100 trust is this normal ? or is there an issue with me dedi box?

Most likely it just didn't shut down properly. Should start regaining trust within an hour or so.

Update from 1.2.5 to 1.4.1.
Need to update from java-1.6.0-openjdk to java-1.7.0-openjdk. And sqlite-jdbc-3.7.2.jar seems not necessary any more.
It seems I'm outdated for a long time.

Do I need to rename folder downloaded to download? Thanks.

This post has been edited by Samcall: Feb 20 2017, 17:51

Do I need to rename folder downloaded to download? Thanks.

No, the downloader does not exist anymore: /index.php?showtopic=191285

No, the downloader does not exist anymore: /index.php?showtopic=191285

Got it. And thanks for the reference.

I'm pretty confused about how things work now. From what I thought I used to know, you had to browse galleries to add to your cache and more popular galleries got you more hits. Was that ever correct or am I imagining things? I have my max burst set to 700KB/s and 500 GB of maximum disk cache size. I've been running the client for months now and my client never exceeds 98.6KB/S and my cache has been around 70 GB. My connection and computer is fully capable of more and in the past the client was running at higher speeds but that before the H@H download button disappeared before I took a few months break. I expected to need to build back up over time after coming back, but it doesn't seem like it's improving. Do I need to do anything to increase my hit-rate? or should this happen on it's own?

I'm pretty confused about how things work now. From what I thought I used to know, you had to browse galleries to add to your cache and more popular galleries got you more hits. Was that ever correct or am I imagining things?

This hasn't been the case for a long time. Now you just need to leave it running.

I need some advice about how to monitor long-term H@H client health status,

as I used to keep H@H client running on my little linux box,
usually it just keep running without problem,

recently I discover the Trust/Quality both drop rapidly then raise again,
but there is no history or other info for me to track where the problem is,

is my client act bad? bad hardware? I got network issue? or my local ISP slap me in the face?
is it dropped only on busy hour? periodically? or random?

I need some info to work on then get start to diagnosis the root cause.

any advise is welcome.

This post has been edited by AndCycle: Apr 20 2017, 22:14

I need some advice about how to monitor long-term H@H client health status,

as I used to keep H@H client running on my little linux box,
usually it just keep running without problem,

recently I discover the Trust/Quality both drop rapidly then raise again,
but there is no history or other info for me to track where the problem is,

is my client act bad? bad hardware? I got network issue? or my local ISP slap me in the face?
is it dropped only on busy hour? periodically? or random?

I need some info to work on then get start to diagnosis the root cause.

any advise is welcome.

The logs ( log_err and log_out ) are a start. If you got throttled you will see speed reduction after a period of good speed.

iostat can give you IO statistics, which may show speed issues with the undelying VPS virtualisation (If disk IO is the biggest bottleneck something is wrong. For that you will need to calculate your maximum average use of disk IO within, say, a minute from the logs and compare to the disk speed)

iptraf can give you connection monitoring. Notably the "General Interface Statistics", since connection by connection monitoring does not make much sense with H@H (and would be overwhelming). tshark plus wireshark as a GUI is an option too.

pidstat -p <H@H pid> -r will give you several major faults ( majfault/s > say 1 or 2) if your box is running out of memory for H@H.

And socat can be used to inspect how quickly the H@H socket is sending stuff. But this one is rather complex and will not give much more info than the logs already give. So I would not recommend unless you are out of options.

My 2c:

Monitor how much time your system spends in iowait, and which processes are in D disk.

$ top
top - XX:04:14 up XX days, 1 user, load average: 0.12, 0.35, 0.46
Tasks: 217 total, 1 running, 216 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.2 us, 0.7 sy, 0.0 ni, 97.7 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st

Use a network monitoring tool to monitor network health stats such as latency, packet loss. I use smokeping and collect stats to my ISP and to other networks of interest.

thanks for all advise,

the log doesn't show much info for this,
looks normal, there is just not much connection request coming in,

as my H@H live on powerful PC with other service,

E3-1231v3, 32GB ECC ram, dedicated SSD for H@H, and it's on ZFS,

although H@H live with other service,

the underlay usage is quite low,
cpu/mem/disk usage, iowait, is in normal range,

munin doesn't really show much different in years,
so the bet is on network side,

I do have smokeping setup,
just for some general info, I didn't add rpc.hentaiathome.net in first place,

but from smokeping it do show unusual high packet lost start to increasing few months ago when reaching U.S. Google IPv6 DNS,
and my static ipv4 addr. is not able to connect to some China site,

so I request my ISP to change my static IPv4 addr,
then problem solved, for now,

is there any site good for smokeping to make some baseline?

i cant download resampled archive
stuck at queue or something