[X] My Assistant

A new version of Hentai@Home was released. Primarily this improves the handling of static range files, and fixes some edge cases that could lead to minor errors.

As part of these fixes, the minimum disk space requirement per static range was increased, as the previous requirement was a bit on the optimistic side. If you have a client with a lot of static ranges, and it's been struggling with a low quality rating for some time, you may want to bump up the allowed space by about 20% if possible. If this is not done, and your client appears to be struggling, some ranges could be withdrawn to help it out of that situation.

This would only have been an issue if you went past a couple hundred ranges or so.


Patch notes for the program update itself:

- Changes to static range handling to prevent very old static range files from being preserved indefinitely. (Only applicable on clients that have been around for a long time.)

- Fixed old file pruning when a static range file has the oldest access timestamp. Pruning is now allowed to remove static range files, but this would only happen they haven't been accessed for more than a year.

- Added functionality to handle allowing static ranges to be removed individually instead of all or nothing, without having to rebuild the database.

- The system will no longer make a backup of the file access database on startup. In case of corruption, rebuilding the database is almost always the best option.

Edit: A very minor update to this build was pushed on 2014-12-28. The only change is turning off auto-commit during the cleanup process for removed static ranges, which will speed it up by a good bit.


Download from the usual place.

For information on how to join Hentai@Home, check out The Hentai@Home Project FAQ.

How long this should take?

CODE

2014-12-13T18:14:29Z [info] CacheHandler: Checking future lasthits on non-static files...

It's going 20 mins on 11GB cache after static range reset T_T

How long this should take?

CODE

2014-12-13T18:14:29Z [info] CacheHandler: Checking future lasthits on non-static files...

It's going 20 mins on 11GB cache after static range reset T_T

Takes me less than a second on a 5 GB cache and about 5 seconds on a 40 GB cache.

Could you grab a copy of your database file and send it to me? Then just delete it and let it rebuild, and see if it still hangs.

Edit: Oh, you reset your static ranges. I suppose it could end up taking some time in that case, but 20 minutes seems a bit much. Is it still outputting debug info about reseting timestamps in the log file?

It's OK now. It took around 40 mins to reset lasthits for all files.
Looks like it was reseting 10-15 files per second. I guess my VPS is not fastest.

It's OK now. It took around 40 mins to reset lasthits for all files.
Looks like it was reseting 10-15 files per second. I guess my VPS is not fastest.

Yeah, seems like I forgot to switch of auto-commit mode for that bit. Which made it I/O bound. Which made it slow if you had a bunch of files and bad I/O.

Doesn't warrant a re-release though, and if you wipe your static ranges, it's still recommended to just nuke the cache entirely.

lol... it has been so long since i have updated my H@H that i have forgotten how to do it.

so which folders do i copy over from my old H@H?

stop H@H.

overwrite all .jar files with the ones that come from the .zip

start it again.

GOOD JOB

Good Job with the update

a shame that it dosen't seems to like my port anymore


(and on the old version: no matter how much mb i give to it - i always get a heap size error when i go lower than 1100mb but since a few days java throws an error when i want to use 1100mb)

Just updated - no hassle.

This would only have been an issue if you went past a couple hundred ranges or so.

Nice update.

I wish AHPM would be shown on H@H page.

Can someone help me get this vps script to autorun? I ended up doing it as root because with a user I couldn't get the script to work and starting it without the script only worked with sudo I figure running it as root is no big deal since it's a virtual server anyhow and h@h is all I use it for..

Anyhow I followed the instructions at
http://ehwiki.org/wiki/Installing_H@H_on_Debian

And the script works but I can't get it to autorun on startup- here's what I got when I tried to set it to autorun
root@install:/etc/init.d# update-rc.d hentaiathome defaults
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
update-rc.d: using dependency based boot sequencing
root@install:/etc/init.d#

Didn't see a subforum for hentai@home so let me know if there's somewhere else I should post this?

Edit: found another way to make it autorun
Chrontab -e
Add this at end of file:
@reboot /etc/init.d/hentaiathome start

This post has been edited by lolwutusay: Dec 17 2014, 02:51

A new version of Hentai@Home was released. Primarily this improves the handling of static range files, and fixes some edge cases that could lead to minor errors.

As part of these fixes, the minimum disk space requirement per static range was increased, as the previous requirement was a bit on the optimistic side. If you have a client with a lot of static ranges, and it's been struggling with a low quality rating for some time, you may want to bump up the allowed space by about 20% if possible. If this is not done, and your client appears to be struggling, some ranges could be withdrawn to help it out of that situation.

This would only have been an issue if you went past a couple hundred ranges or so.

Wow, 1.2.2 seems to have helped some of my clients that were struggling at 4000 quality to go up above 7000.

(and on the old version: no matter how much mb i give to it - i always get a heap size error when i go lower than 1100mb but since a few days java throws an error when i want to use 1100mb)

Mine seems to successfully stay around +/- 128MB.

CODE

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
28143 hah       20   0  418m 123m  11m S   3.3  6.0  83:20.06 java

I set this environment variable:

CODE

export _JAVA_OPTIONS="-Xmn32m -Xms128m -Xmx128m -Xss256k -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:NewSize=10m -XX:MaxNewSize=10m -XX:SurvivorRatio=32 -XX:TargetSurvivorRatio=80 -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:PermSize=32m -XX:MaxPermSize=32m"

root@install:/etc/init.d# update-rc.d hentaiathome defaults
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
update-rc.d: using dependency based boot sequencing
root@install:/etc/init.d#

There's nothing wrong with that output. If you really want it to run without outputting the warnings you can do this:

CODE

export LC_ALL=C
export LANG=C
update-rc.d hentaiathome defaults

(Running "update-rc.d hentaiathome defaults" several times isn't harmful.)

Finally, to check that the script will boot H@H at boot do:

CODE

sysv-rc-conf  --list | grep hentai

and see if there is any output

There's nothing wrong with that output. If you really want it to run without outputting the warnings you can do this:

CODE

export LC_ALL=C
export LANG=C
update-rc.d hentaiathome defaults

(Running "update-rc.d hentaiathome defaults" several times isn't harmful.)

Finally, to check that the script will boot H@H at boot do:

CODE

sysv-rc-conf  --list | grep hentai

and see if there is any output

Found a workaround like I said (It wasn't running at boot) but out of curiosity:

root@install:/etc/init.d# sysv-rc-conf --list | grep hentai
hentaiathome 0:off 1:off 2:on 3:on 4:on 5:on 6:off

I found another way to get the script to autorun using chrontab @reboot

root@install:/etc/init.d# sysv-rc-conf --list | grep hentai
hentaiathome 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This means that the script will be run every time the machine is booted (i.e. that the command to load the script worked)

I found another way to get the script to autorun using chrontab @reboot

Now, if you have the output above *and* that line in crontab the script will run two times (once by itself and once when crond starts). This shall be harmless as the script itself check if H@H is already running and do not start it if this is the case. (but you can remove the crontab line if you want)

Wow, 1.2.2 seems to have helped some of my clients that were struggling at 4000 quality to go up above 7000.

I've had the same issue with a bit over 200 static ranges... and just updated.

I see your post is three days after the release. How long did it take for the quality to improve above 7000?

I've had the same issue with a bit over 200 static ranges... and just updated.

I see your post is three days after the release. How long did it take for the quality to improve above 7000?

It's not generally going to make the quality improve all by itself. What you can do right now is increase the disk space slightly, which will give it some breathing room. If that's not possible, I'll soon do a pass on the clients that have upgraded and that are struggling, to remove a few ranges - the client will then have to be restarted, which will make the usual LRU mechanism take effect.

I could do yours as a test, if you want.

I could do yours as a test, if you want.

Please do! I cannot add more space at the moment. Similar to a post below, it is a VM dedicated for H@H, and all available space is already assigned for H@H.

If you have a client with a lot of static ranges, and it's been struggling with a low quality rating for some time, you may want to bump up the allowed space by about 20% if possible. If this is not done, and your client appears to be struggling, some ranges could be withdrawn to help it out of that situation.

This would only have been an issue if you went past a couple hundred ranges or so.

- Added functionality to handle allowing static ranges to be removed individually instead of all or nothing, without having to rebuild the database.

oooh VERY NICE. I have been waiting for an update that allows for reducing static ranges without resetting the cache.

I have one client with 1116 ranges that is struggling mightily for over a month now. gets over 4000, then crashes to 3000. I increased the cache space to see if h@h would work itself out, but it hasn't helped. I assumed there was just not enough space for so many ranges, since other clients I have contain ~600 ranges but use the same amount of hard disk space.

I haven't upgraded to this 1.2.2 yet; I have a question: 1. how do you withdraw from some static ranges? Can I do that via command prompt or do you have to do that manually? I have 4 clients, each with over 1000 ranges that I'd like to have reduced, then I will increase their cache size.

This post has been edited by treesloth: Dec 20 2014, 03:00