[X] My Assistant

Is it possible to support IPv6 in the future?

/index.php?showt...p;#entry1997109

Hello,

I have been running 1.6.0 since its release, and have had it running pretty well. Over the ~60 uninterrupted hours that I have had it online, my Quality and Trust have been solid at 7-8k and 1k, respectively. Unfortunately, about half an hour ago, I noticed that these numbers had tanked, hard. I am now sitting at <2k Quality and negative Trust. I have changed no settings with my computer or network, my hardware resources are not constricted, and a cache validation completed without failure.

Anyone else running into this sort of issue, lately? I am logging a ton of the following warnings, errors, faults, etc.:

java.net.SocketTimeoutException: connect timed out
java.net.SocketTimeoutException: Read timed out

The connection was interrupted or closed by the remote host.
Connection reset by peer: socket write error

An error has occurred. (400)

I have shut down my client, in order to prevent my Trust number from tanking any further. Would appreciate some help on this.

EDIT: I turned my client back on after a couple hours. My Trust has recovered back to 1k, but it will take a while for the Quality to recover, I suppose. I do not know what caused the blip I experienced, but it does not appear to have been on my end (unless my ISP was having an issue that was not visible within my monitoring software).

Regards,
Blue

This post has been edited by bluestealth: Jan 5 2020, 14:54

I don't know how you've pulled that out tenbro, but since I'm running H@H 1.6.0 instead of 1.4.2 I've got this:



Perfect Trust+Quality at all times. I'm wondering if I can raise the max speed now. Awesome job dude.

I don't know how you've pulled that out tenbro, but since I'm running H@H 1.6.0 instead of 1.4.2 I've got this:



Perfect Trust+Quality at all times. I'm wondering if I can raise the max speed now. Awesome job dude.

Same, been getting perfect trust+quality even on rush hours since changing from 1.4.2 version to first 1.5.4 then 1.6. I have my limit on 44000 though since I actually use my server for other things.

I don't know how you've pulled that out tenbro, but since I'm running H@H 1.6.0 instead of 1.4.2 I've got this:



Perfect Trust+Quality at all times. I'm wondering if I can raise the max speed now. Awesome job dude.

my max-speed just stuck at 26xxx no matter which version of java i run the client on my raspberry pi 4!
it runs at full speed of 80000 before. What machine do you run it on?
PS: i use home connections, is there any possibility that my ISP imposed bandwidth limit on certain ports?

This post has been edited by Me1_base_honor: Jan 8 2020, 12:04

I haven't really got anything to complain about. But I was wondering if anyone has any tips for making the H@H client an auto-starting service in ubuntu? Lowkey tryna get my server in a state where I can get it to auto run updates n shit every night and having to manually restart the client sorta defeats that purpose...

I haven't really got anything to complain about. But I was wondering if anyone has any tips for making the H@H client an auto-starting service in ubuntu? Lowkey tryna get my server in a state where I can get it to auto run updates n shit every night and having to manually restart the client sorta defeats that purpose...

Crontab

hi,guys.
Could I get gallery id from cached file path?
I use H@H 1.6.0.I like watching dimly cached file.
I got fave Image. and I'm interested in original staff.
so could I get original gallery id from cached file path?.
for examle,
How to get those content (http://ehentaihip.com/s/0658ddf2a/70381-3) from cached file that under H@H cache folder.
cache/06/58/0658ddf2a2d814122ae18c47a2ef920007a4ac9f-580169-1241-1600-jpg.
Please let me know if you can.

when using "click here if the image fails loading", the page will try to reload the image from source through http, which I guess should also be migrated to https.

when using "click here if the image fails loading", the page will try to reload the image from source through http, which I guess should also be migrated to https.

The image servers don't do HTTPS yet, but they will eventually.

my max-speed just stuck at 26xxx no matter which version of java i run the client on my raspberry pi 4!
it runs at full speed of 80000 before. What machine do you run it on?
PS: i use home connections, is there any possibility that my ISP imposed bandwidth limit on certain ports?

SSL may be a big part of it. Rpi (or ARM in general) has no opimized SSL handshake libraries, so SSL is a particularly big hit on the Pi

Crontab

Just to add on two cents here... The more recent Ubuntus (or however you pluralize that) don't actually use cron directly, they use something else - systemd, I believe? I think it's systemd.

Yes, this is a nitpick, and it's moot one at that - systemd knows how to read cronfiles, and so if you make a crontab entry it will work perfectly fine. Plus, its probably less effort to make a crontab entry than it is to create/install something as a systemd service; just "crontab -e", add a single line, save, and bam it's done. (Well, assuming you don't fudge up the first bit of the crontab line that says when to run it, like I tend to do. But that's besides the point.)

However, sometimes it does make more sense to make an actual systemd service. Usually when there's common service-like behavior that would require writing boilerplate logic, or dependencies, etc. For example, I have a small web app behind nginx, with both configured as systemd services; I can start or stop them at will (or reload nginx's configuration as well), and if I start the app while nginx is stopped, it will auto-start nginx for me. It also keeps a limited log of stderr, so if I do something dumb I can check that (instead of it getting discarded like a cron stderr would without explicit logging).

So, if making a crontab entry works out well, then great. If not, try looking into systemd; it's got more complexity but more features as well.

I have same speed issues with my Raspberry Pi 3B.
Before the change, the maximum speed can reach the burst speed 100000KB/s,
after I upgraded the H@H client, the speed dropped to 8972 KB/s.

I am planing to switch to Atomic Pi, which is a x86 CPU board.

Performance problems on Raspberry Pis might be related to lack of hardware AES. I believe it might be solved, or at least made easier by adding ChaCha20-Poly1305 cipher suite (which is known to work much faster on systems without hardware ciphers) support to H@H client and placing it on top of server cipher preference.

I am planing to switch to Atomic Pi, which is a x86 CPU board.

x86 it's not enough, you still have to check if the CPU has hardware acceleration for AES.
From what I can see in Intel site the Atomic Pi processor has the AES-NI extensions so you're covered, but not all atom cpus are that lucky.
Last time I had to transfer 300+GB from one old atom to another (rsync over ssh) it took forever since no hw acceleration + openssh disabling arcfour in 7.6 means I couldn't break the 5MB/s barrier.

Crontab

I highly advise against installing H@H as a service. It prevents one from shutting it down properly.
If I've written the wiki tutorial to run H@H with screen for Debian (the same can be done with Ubuntu I guess), there's a good reason for it.

I highly advise against installing H@H as a service. It prevents one from shutting it down properly.
If I've written the wiki tutorial to run H@H with screen for Debian (the same can be done with Ubuntu I guess), there's a good reason for it.

I am now running H@H in a docker container, the docker daemon should stop the H@H service first when the shutdown command be sent.

This post has been edited by cb000: Jan 10 2020, 08:55

I highly advise against installing H@H as a service. It prevents one from shutting it down properly.
If I've written the wiki tutorial to run H@H with screen for Debian (the same can be done with Ubuntu I guess), there's a good reason for it.

I mean I was naturally going to run it in tmux but still as a service.

Perhaps dumb question (and perhaps one that I would know the answer to if I ran H@H, but I don't have the upload speeds to), but why is it so ill-advised to run H@H as a service? Or more accurately, why are things like screen or tmux required? The wiki page for Debian mentions screen, but the Ubuntu one just does a fire-and-forget with nohup (recommending kill to stop it), and Ubuntu and Debian aren't exactly worlds apart.

I mean, If it's just a mechanism to close it out gracefully, there's gotta be a dozen ways to do that which don't necessitate a persistent screen/tmux. (And besides, if part of the goal is to let it close gracefully, using screen/tmux mean that you would have to manually kill H@H before running shutdown, right? If you forget that manual step before a shutdown, then you're not really any better off than a nohup/crontab. That's honestly part of the reason service managers exist - to automate startup and shutdown.)

...Maybe H@H runs more like an interactive command than a daemon, like with a curses interface or something, and you lose that if you just nohup it? Otherwise I'm just kinda confused. And looking through the wiki, I see images of a Java GUI, and maybe a browser-based interface, but nothing that I can find about what the actual stdin or stdout look like.