Posted Sat, 21 February 2015, 11:52 UTC by Tenboro
Due to a large increase to the number of brute-force login attempts against member accounts, there have been some hardening changes made to the login mechanism to thwart this. For most of you this will never come into play, but if you fail multiple login attempts or connect from what the site considers a suspect IP, you will now also have to solve a captcha for every login attempt. Hosts that fail a large number of attempts may be shut out entirely.
Note that if you are using a weak password, one that closely resembles your login username, or one that you've reused on other sites, you may want to change it just to be safe.
Posted Sun, 08 February 2015, 11:00 UTC by Tenboro
A small patch with a couple of requested improvements to the Bitcoin donation interface.
- You can now request a new wallet address once every 24 hours. Previously generated addresses will still work, but they aren't listed.
- There is now an option to send an "official" message with your current wallet address to another member via a forum PM. (Don't abuse this as a begging mechanism, or you will be locked out.)
- Slightly revamped how the logs are displayed. All the "spending logs" are now at the bottom, and the transaction log will now become scrollable instead of stretching the page if you go past a dozen or so.
Posted Sat, 07 February 2015, 11:34 UTC by Tenboro
This is another performance improvement release. Unless you're having either of the issues below, it's not strictly necessary to update.
- Some inefficient code in the random data generation used for speedtests was replaced with a much faster (10-12x) version. This should decrease CPU spikes during speed testing, and potentially give higher tested speeds if the CPU was capped. (Thanks Hobbitmon)
- 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.
- Made log flushing on program shutdown more consistent.
To update an existing client: shut it down, download Hentai@Home 1.2.5, extract the archive, copy the jar files over the existing ones, then restart the client.
- Dropped unnecessary legacy wrapping class when generating cache lists, which should slightly reduce memory overhead during startup.
- Fixed a bug in the StringBuilder initialization for the Cachelist processor that lead to it allocating a buffer that was much larger than intended, which could lead to out-of-memory errors during startup with caches of certain size ranges.
- Files that were part of a removed static range will now be deleted at first startup instead of being shuffled into the dynamic file pool. They would see very little traffic, and this should cause less server overhead and avoid breakage on systems with very slow CPUs.
Note that while versions prior to 1.2.0 have not been allowed to start up for a month or so, there were still 30-ish active clients running 1.0.10. For compatibility reasons, these can now no longer operate until they are updated to 1.2.0 or newer.
To update an existing client: shut it down, download Hentai@Home 1.2.4, extract the archive, copy the jar files over the existing ones, then restart the client.
Interface addition: Added a new checkbox "Verify cache integrity on next startup" on the client settings screen. Checking this will make the client run a full file verification on the next startup, the same effect as starting the client with the --verify-cache command line option.
(This option will automatically be turned off again after the next startup, so you don't have to manually uncheck it.)
Second interface addition: Added checkboxes "Disable logging to disk" (equivalent to --disable-logging) and "Run in low-memory mode" (equivalent to --use-less-memory).
Clients with a large number of files could run into issues where the startup sequence took so long that you hit a server-side timeout. This could particularly happen if you were on a slow CPU, like a Raspberry Pi or a NAS box.
This update changes how cache lists are generated and sent to the server to speed it up by a significant amount. It also refactors part of the startup sequence to happen outside of the critical timeout-able section.
You don't need to apply this update unless you are having issues with slow startups, but it would be nice if some people with very large caches could try it out and compare startup times.
