[X] My Assistant

Hey, I've just started using h@h, right now I'm doing something like this:

CODE

cd hath
~/jva/jre1.8.0_45/bin/java -jar HentaiAtHome.jar

but in a screen.
Is there a way to run h@h in background just as it is?
How should I go about restarting the client(in order to check cache for example) gracefully? I noticed my quality dropping today without warnings in log, so I killed it and started again, which resulted in -100 trust.

I have a seedbox in Finland, Helsinki I guess, but speedtest automatically chooses some place in US and thinks it's the closest location, should I be worried about this kind of behaviour affecting my H@H client?

I am running java this way because the server didn't have it installed and I was looking for a way around it with a normal user access.

if linux you can use tmux

apt-get install tmux
...tmux installed...
type > tmux a
start client.
press ctrl+b d to detach

This post has been edited by karyl123: May 21 2015, 21:30

Thanks!
I'll continue using screen because I like having logs, I was actually trying to use log files instead of output from client.
So a proper way to shutdown is to send Interrupt signal, got it.

There's not much you can do about this. Routing to the proper speedtest server is (probably) directed by the H@H servers.

What I don't want it to do is to get connection from America when the server is in Europe, though I checked some of requests in log and all of them were from Asia xD

I can't install tmux with apt-get, it seems to do the same thing screen does anyway.

yes, tmux and screen is same.

its just like open office and ms office

nice

Can H@H use localtime on linux? (IMG:[invalid] style_emoticons/default/huh.gif)

its so long way. (IMG:[invalid] style_emoticons/default/smile.gif)

Over the last little while (at least a few days, probably more than a week), the quality on all my clients has been dropping overall. They're usually in the 8000-10000 range barring occasional hiccups, but they're now in the 3000-5000 range and still slowly dropping on average.

I was wondering if this was related to the recent H@H handling updates or if it's just some long-term network suckage on my end.

Over the last little while (at least a few days, probably more than a week), the quality on all my clients has been dropping overall. They're usually in the 8000-10000 range barring occasional hiccups, but they're now in the 3000-5000 range and still slowly dropping on average.

I was wondering if this was related to the recent H@H handling updates or if it's just some long-term network suckage on my end.

Nothing quality-related has been changed lately. I'm currently seeing you in the 7-8000 range, so it's probably network-related. 3-5000 is still passable, though.

I recently started using hentai@home, about 24 hours ago.

How long does it usually take for traffic usage to average out? I'm seeing fairly low utilization, I guess it can take a few days to get going - is there a guideline of how many days that would be?

How long does it usually take for traffic usage to average out?

1-2 weeks

Looks like the min_client_build has been increased ... 15 days ago (IMG:[invalid] style_emoticons/default/ohmy.gif) Okay, I know I'm pretty late, sorry, but since I had to port the changes, I have one question:

- With a large cache and under heavy load, having to free disk space would sometimes take a long time and therefore prevent the client from doing anything else that runs from the main thread or requires database access. Some tweaks to the free space generator should now prevent this.

Were the delays related to the removal of the files from the disk (the call to File.delete()) or to the associated database queries (the calls involving sqlite only)?

Were the delays related to the removal of the files from the disk (the call to File.delete()) or to the associated database queries (the calls involving sqlite only)?

The database query was suboptimal, and it was run 20 times instead of just querying 20 files at once because Reasons™. Worked fine until you got a few hundred thousand files, but it was just too slow at that point.

The database query was suboptimal, and it was run 20 times instead of just querying 20 files at once because Reasons™. Worked fine until you got a few hundred thousand files, but it was just too slow at that point.

Okay, thanks for the explanations. I'm glad I chose a design with no db engine then (IMG:[invalid] style_emoticons/default/smile.gif)

THANGKYOU

Thanks !

Been running this for a little over a week now and still seeing very low utilization for disk usage, disk IO, network, CPU. The first few days I would see a quality of ~8K, but now it's lowered to 3.5k~ish and I'm seeing quite a lot of 400 codes which I believe causes them:

CODE

2015-06-23T16:39:06Z [info] {90843/115.87.62.20}    Code=200 Bytes=884162   GET /h/89a711fa38ccebd23f7a8dfe56578ed597d1ce96-884162-1131-1600-png/keystamp=1435077900-03b1d7af26/tumblr_nq78wmRGwv1uywv8zo1_1280.png HTTP/1.1
2015-06-23T16:39:10Z [info] {90843/115.87.62.20}    Code=200 Bytes=884162   Finished processing request in 4.15 seconds (213.10 KB/s)
2015-06-23T16:39:11Z [info] {90846/115.87.62.20}    Code=400 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)
2015-06-23T16:39:11Z [info] {90844/115.87.62.20}    Code=400 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)
2015-06-23T16:39:11Z [info] {90845/115.87.62.20}    Code=400 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)

What would cause stuff like this? I was hoping to see a much higher utilization and quality value.

Been running this for a little over a week now and still seeing very low utilization for disk usage, disk IO, network, CPU. The first few days I would see a quality of ~8K, but now it's lowered to 3.5k~ish

During the first couple of days h@h downloads cache as a priority (it is also prioritised by the server during that period). After it has a decent cache it operates slower.

I'm seeing quite a lot of 400 codes which I believe causes them:

400s are just people fapping too fast, i.e. closing the socket (the tab in the case of a browser) before the entire image is transferred.

Hm alright, well I'll keep it running for a while to see what happens. I'm seeing an average of 500KB/s outgoing and 200KB/s incoming, with little peaks to about 1500 / 500KB respectively when it's "busy". This is for a server in the UK.

Over the last 9 days it only downloaded 4GB of caching data. it seems a bit low to me, but we'll see what happens (IMG:[invalid] style_emoticons/default/smile.gif)

I have no issues with my client, pretty much constantly at 1000trust/10000quality.

I have another issue though. I have a h@h file that simply won't start downloading. It's in the hathdl folder, like all the other ones, but it never got cleared and it never caused even an empty folder to be created for the gallery. I tried redownloading the file a few times to make sure there are no issues, but it just won't download.

Any ideas what the reason for this could be? And before you ask, other hathdl files downloaded the galleries just fine, and my client has been running for several days without interruption now, so it's not that.

A thing to note, I noticed the gallery is marked as "RES" - resized for online viewing. But I don't think that should have anything to do with the download. Yes?

^ can you post the hathdl file?