[X] My Assistant

1.0.5 Release Notes

- The automated connection limiter now defaults to calculate the limit in a different way whenever max speed is set, which should prevent very fast clients from running into the limit during the period right after a restart.

- The client's uptime and various stats now start counting from when it finishes starting up, instead of from when the program is launched.

- The average speed counters are now less jumpy right after startup.

- Increased the retry counter for failing H@H image downloads from 10 to 100.

- Added better file buffering for image file reads.

- Removed the startup argument --skip-live-hash, as files are now always read through a buffered stream.

- Added the startup argument --disable-logging, which turns off the standard output log file.

- Calculating the stats for the file list during startup should now be much, much faster for large caches (100,000+ files).

- Added a workaround for a limitation in Java that caused file distibution to fail if the /tmp and/or the /cache directory were symlinked elsewhere in a way that caused them to end up on different file systems.

- The unmaintained "import" functionality was removed.

- Added the experimental argument --use-more-memory, intended for very fast clients, which applies the following optimizations:

-- Activates a new mechanism in the cache handler for reducing the disk I/O overhead related to tracking file usage statistics. Over time, this reduces housekeeping I/O by 75-80% on high traffic clients.

-- Increases the buffer size for generating the file list during startup from 1000 to 25000, which will help clients with a very large cache start up faster.

-- Increases the buffer size for reading image files from 8K to 64K.

Note that depending on your RAM size and OS, unless you explicitly set a larger heap size for the Java process, this setting could potentially make the Java VM run out of RAM. To set a larger heap size, you have to start the client from the command line like this:

CLI: java -Xmx512m -jar HentaiAtHome.jar --use-more-memory
GUI: javaw -Xmx512m -jar HentaiAtHomeGUI.jar --use-more-memory

Download from the usual place.

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

yarp, I'll get on it. Too bad I'm not one of those super fast super big clients~

So if I'm running the pre-release 1.0.5....should I swap out for the official?

Oh and yes the increase is a marked improvement if you're able to upload megabytes per second.

So if I'm running the pre-release 1.0.5....should I swap out for the official?

There's not much difference between the RC and the final release, and I can't recall fixing any critical bugs, so there's no hurry anyways.

(IMG:[invalid] style_emoticons/default/blink.gif) Lol

(IMG:[invalid] style_emoticons/default/blink.gif) Lol

Seriously, man, first post to say this? (IMG:[invalid] style_emoticons/default/ohmy.gif)

Seriously, man, first post to say this? (IMG:[invalid] style_emoticons/default/ohmy.gif)

Quoted for Truth!

I was hoping for ".fail" fixes...

The ".fail" fix involves turning off PeerBlock. You can't expect H@H to work when there are programs that actively work against it.

When will this upgrade be compulsory? xD.

Considering that 1.0.3 is still usable, I don't expect it to be any time soon.

Maybe you should offer a bounty - upgraders get a/(1+e^bx) hath where x is the number of seconds after release. Be sure to set sensible values for a and b though.

that would *sure* quicken adoption... And make upgrades a lot more popular (IMG:[invalid] style_emoticons/default/smile.gif)

EDIT: what can we delete now? Seems to me like at least import/ is superflous:

CODE

atom@nanika /srv/hath $ ls -F
cache/  data/  downloaded/  hath*  hathdl/  HentaiAtHome.jar  import/  sqlitejdbc-v056.jar  stdout.log  tmp/

also:

CODE

atom@nanika /srv/hath $ find | grep -v -e 'cache/'
.
./data
./data/log_out
./data/client_login
./data/hath.db.bak
./data/log_out.old
./data/log_err.old
./data/log_err
./data/hath.db
./stdout.log
./hathdl
./tmp
./HentaiAtHome.jar
./downloaded
./cache
./sqlitejdbc-v056.jar
./import
./hath

./hath and ./stdout.log are due to my hath setup, but everything else is hath's doing. What can I delete? the import/ folder is a candidate, also tmp/ and hathdl/ and downloaded/ seem empty. I'm sure some of those are used from time to time, but are they deletable?

Regards,

atomicity.


This post has been edited by atomicity: Oct 26 2010, 22:10

Only the import folder. The rest are in use, but the program will simply remake them if they are removed.

then what would a beta-tester or pre-release tester get for a hath bonus?

Is a problem of escalation ...at a certain point, it just becomes a Hath being thrown around like rainbows and pixie dust!

nice (IMG:[invalid] style_emoticons/default/biggrin.gif)

nice xd

Did something change in the H@H toplist calculation ? It seems the score of those who have adopt some slots is much higher than previous weeks, while the score of the other users is lower (IMG:[invalid] style_emoticons/default/unsure.gif)

Hmm. Yeah I know what would have caused that, and it's not intentional. Should be fixed... but let me know if it doesn't return to normal.

Thanks, I will. The scores of Saturday H@H toplist are still higher than before, but I guess we have to wait a full 24h for your fix to show up.

You won't see it tomorrow either, but I tracked down the actual bug causing it. So it sound be fixed, uh.. the day after tomorrow.