[X] My Assistant

1) Since I updated to H@H 1.2 my clients max speed reach to 5-10 MB/s but with the previous it was reaching the max speed 28MB/s (80%*35MB/s). Maybe it is a problem with my clouds (hope not) or maybe i didnt do the update right (i only replaced the 3 files given in the update).

Use --disable_bwm , in the tens of MBs speed there shouldn't be any reason to not use it.

Help don't know where to ask but I have a problem with my H@H it is says there port has a problem and it shuts down but the client on the site it is online and I cant change the port.

Most probably something else is using the port, and therefore you shall eithe investigate what is using it or change the port.

btw, logs, error messages and some machine output would be useful.

IDC about the port problem i care that it is shut down but the client shows it online

(IMG:[imageshack.com] http://imageshack.com/a/img593/2858/y1z2.png)
------------------------
(IMG:[imageshack.com] http://imageshack.com/a/img543/3126/8v1v.png)

IDC about the port problem i care that it is shut down but the client shows it online

But it is online. It last checked in three minutes ago when I write this.

I cant see anything running and this is what happens when I try to run it (time here gmt+2)
(IMG:[imageshack.com] http://imageshack.com/a/img547/728/n4wc.png)

Most likelly it is working fine, haven't you started it from the command line without the "GUI" part in the jar name by a chance?

(Go into the task manager and search for some process running java)

restarted (why didnt think of that earlier (IMG:[invalid] style_emoticons/default/sleep.gif) ) and everything s fine now (IMG:[invalid] style_emoticons/default/smile.gif)

now remains the --disable_bwm to mange and do it (IMG:[invalid] style_emoticons/default/tongue.gif)

I know it would be preferred to keep H@H running indefinitely with minimal downtime, but would it especially hurt a client's trust if I left mine running for only ~60 hours over the weekend per week? Or rather, is that much too short a period of time overall?
EDIT: Actually all I really need to know is approximately how many minimum hours of 168 a week I would have to keep the client running to be considered acceptable.

This post has been edited by AntiGod: Feb 8 2014, 02:28

Clients that get below 40 KB/s receive no hath. The absolute minimum limit was always 50 KB/s.

*Looks at his 4 years of H@H service*

*Looks at his hundreds and hundreds of Hath earned at 20kB/s*

*blushes* (IMG:[invalid] style_emoticons/default/blush.gif)

So, ah, I'd like to amp my upload to 50KBps now that I got a boosted connection, if that's cool? Didn't even realize I had stopped getting hath until just now (IMG:[invalid] style_emoticons/default/ohmy.gif)

So, ah, I'd like to amp my upload to 50KBps now that I got a boosted connection, if that's cool? Didn't even realize I had stopped getting hath until just now (IMG:[invalid] style_emoticons/default/ohmy.gif)

You can do it yourself from here: https://e-hentai.org/hentaiathome.php

You can do it yourself from here: https://e-hentai.org/hentaiathome.php

Ah damn I was just staring at that before I asked, I forgot the client name was a link. Duh. Been a while since I've tweaked this thing . . .

Thanks!

After I updated to H@H 1.2.0 my clients dont reach max speed 28MB/s (80%*35MB/s) anymore, they are constantly at 4-5MB/s speed. I used --disable_bwm but didn't do much. I ran some speedtests on my clouds and the upload speed seems fine.

I can't post an image, but are my Avg. Bytes Rec/Sent supposed to be <10KB/s?

My port is open, so I can't seem to figure out what's wrong.

My quality is getting hammered because some other server is failing, and I end up with empty files:

CODE

2014-03-10T03:15:01Z [info] {544/60.160.190.26}   Code=403 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)
2014-03-10T03:15:11Z [info] {545/60.160.190.26}   Code=403 Bytes=28       GET /h/7f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg/keystamp=1392087900-9f4ea2700e/img047.jpg HTTP/1.1
2014-03-10T03:15:11Z [info] {545/60.160.190.26}   Code=403 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)
2014-03-10T03:15:11Z [info] {546/60.160.190.26}   Code=403 Bytes=28       GET /h/7f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg/keystamp=1392087900-9f4ea2700e/img047.jpg HTTP/1.1
2014-03-10T03:15:11Z [info] {546/60.160.190.26}   Code=403 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)

There's thousands of lines of that.

CODE

2014-03-10T03:15:11Z [info] {546/60.160.190.26}   Code=403 Bytes=28       GET /h/7f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg/keystamp=1392087900-9f4ea2700e/img047.jpg HTTP/1.1
2014-03-10T03:15:11Z [info] {546/60.160.190.26}   Code=403 Bytes=28       Finished processing request in 0.00 seconds (-.-- KB/s)

Have you checked user permissions on all files in the cache? Maybe you started H@H as root by accident at some point and stopped it quickly, then started as the right user. With http 403 I always suspect permissions.

Have you checked user permissions on all files in the cache? Maybe you started H@H as root by accident at some point and stopped it quickly, then started as the right user. With http 403 I always suspect permissions.

I run the server as root inside its own VM. I also just double checked the file permissions (chown -R'ed the entire H@H folder). Still getting it.

It shouldn't matter as it's the same user that is creating and reading the files (and also root has read permission to everything) but just in case cross check the chmod permissions too. root often has a different umask from other users.

Also you could check if the keystamp is right, if it isn't someone decided to hotlink the image stored on your H@H cache. i.e. say we try with this one

CODE

/h/7f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg/keystamp=1392087900-9f4ea2700e/img047.jpg HTTP/1.1

The first part is the time: 1392087900 (I'll call it <ktime> below)
The second one is a hash: 9f4ea2700e
Calculated as: sha256sum(<ktime>-<file>-<your client key>-hotlinkthis)
so for the example above:

CODE

sha256sum("1392087900-f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg-CLIENTKEY-hotlinkthis")

(PS: I'm not 100% sure whether it's sha256sum or sha1sum)
(PSPS: Tenboro's ingenuity in preventing hotlinking is peculiar)

It shouldn't matter as it's the same user that is creating and reading the files (and also root has read permission to everything) but just in case cross check the chmod permissions too. root often has a different umask from other users.

Also you could check if the keystamp is right, if it isn't someone decided to hotlink the image stored on your H@H cache. i.e. say we try with this one

CODE

/h/7f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg/keystamp=1392087900-9f4ea2700e/img047.jpg HTTP/1.1

The first part is the time: 1392087900 (I'll call it <ktime> below)
The second one is a hash: 9f4ea2700e
Calculated as: sha256sum(<ktime>-<file>-<your client key>-hotlinkthis)
so for the example above:

CODE

sha256sum("1392087900-f24246c234e917e21e3b3fc21003d0e8dfd4985-505311-1024-1519-jpg-CLIENTKEY-hotlinkthis")

(PS: I'm not 100% sure whether it's sha256sum or sha1sum)
(PSPS: Tenboro's ingenuity in preventing hotlinking is peculiar)

It does a case-insensitive comparison between the keystamp hash and first 10 characters of the hash provided by a digest function that isn't guaranteed to be anything (Blame the [docs.oracle.com] documentation)

And, assuming I'm doing this correctly, neither a sha256 or sha1 hash match. It's also only that IP, retrying the exact same file over and over. Firewall time.

(PS: I'm not 100% sure whether it's sha256sum or sha1sum)

It's SHA-1. That function is from an old-ass file with some convenience functions I wrote like fifteen years ago (before SHA-256 and the rest of the SHA-2 family were created), so it was implied (and apparently they still alias it to SHA-1). Though I should probably make it explicit.