[X] My Assistant

1.1.3 Release Notes

- (Core) The database schema was altered to remove the unused strlen field. Note that the existing database will automatically be updated on first startup, after which you cannot downgrade without deleting the database.

- (Core) The client should now be able to understand requests that use encoded equal signs (=) in the URL.

- (Core) The client will now enforce available cache size, and will therefore no longer start if the setting for the cache size is larger than the available disk space minus the total size of the files in the cache. (You can adjust this from the web interface.)

- (Core) Added a safety check to prevent the client from starting if it has static ranges assigned but an empty cache, which would indicate some sort of error. (To start a client that has lost its cache, you have to manually reset the static ranges from the web interface.)

- (Web Interface) Added an option to reset static ranges, for those cases where the cache has been lost for some reason or another.

- (Web Interface) Instead of having it as a warning, the interface screen will now simply refuse to change a client's port or key while it is running.

- (Dispatcher) The trust mechanics was tweaked to take static ranges better into account. Depending on the number of assigned ranges and frequency of requests, a request for a static range file can now cause a slight reduction in trust. The effect should be very minor for well-behaving clients (and will be adjusted if it's not), and is solely to prevent clients with frequent cache wipes from having ranges assigned.

- (Dispatcher) New static ranges can now only be assigned to a given client once every two hours. Additionally, they will not be assigned unless the client has been running for at least 24 hours.


As the 1.1 branch is considered Beta, it's not added to the H@H client page. Download it here:

Runnable
Source

(Note that the initial r82 and r83 builds were pulled due to missing functionality/bugs, current build number is r84.)

- (Core) The client will now enforce available cache size, and will therefore no longer start if the setting for the cache size is larger than the available disk space minus the total size of the files in the cache. (You can adjust this from the web interface.)

So... i currently have 118Gb files in cache (100% cache utilization) and 75Gb total space on disk with ~1Gb free. (I use symbolic links)
As i understand 1.1.3 won't start.
Or maybe it will???

The hetaiathome page says my client's version is "Unknown-r82".
Is this normal?

So... i currently have 118Gb files in cache (100% cache utilization) and 75Gb total space on disk with ~1Gb free. (I use symbolic links)

Well, if you use symlinks, the client won't be able to determine free disk space properly anyway. There is a startup flag --skip-free-space-check you can use in this case, but I noticed I forgot to add it to the recent check. Just put up a build where this was fixed.

Keep in mind that when you use this, the onus is on you to make sure there is always enough disk space available.

The hetaiathome page says my client's version is "Unknown-r82".
Is this normal?

You know, I always forget to update that thing.

Tried running 1.1.3 in a new dictionary, got this error

2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} Critical Error: This client has static ranges assigned to it, but the cache is empty.
2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} Check permissions and, if necessary, delete the file hath.db in the data directory to rebuild the cache database.
2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} If the cache has been deleted or is otherwise lost, you have to manually reset your static ranges from the H@H settings page.

After resetting, this error:

Exception in thread "Thread-0" 2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} java.lang.NullPointerException
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.Settings.getStaticRangeCount(Settings.java:464)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.CacheHandler.initializeCacheHandler(CacheHandler.java:280)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.HentaiAtHomeClient.run(HentaiAtHomeClient.java:124)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at java.lang.Thread.run(Thread.java:744)

Went back to 1.1.2 and everything ran just fine.

On another server, ran 1.1.3 smoothly in the same dictionary.

Tried running 1.1.3 in a new dictionary, got this error

2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} Critical Error: This client has static ranges assigned to it, but the cache is empty.
2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} Check permissions and, if necessary, delete the file hath.db in the data directory to rebuild the cache database.
2013-12-13T16:55:52Z [ERROR] {org.hath.base.HentaiAtHomeClient.dieWithError(HentaiAtHomeClient.java:285)} If the cache has been deleted or is otherwise lost, you have to manually reset your static ranges from the H@H settings page.

That's normal.

After resetting, this error:

Exception in thread "Thread-0" 2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} java.lang.NullPointerException
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.Settings.getStaticRangeCount(Settings.java:464)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.CacheHandler.initializeCacheHandler(CacheHandler.java:280)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at org.hath.base.HentaiAtHomeClient.run(HentaiAtHomeClient.java:124)
2013-12-13T16:42:37Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Throwable.java:748)} at java.lang.Thread.run(Thread.java:744)

Obvious crash bug is obvious.

I pushed another build. Try that one.

(Note that the initial r82 and r83 builds were pulled due to missing functionality/bugs, current build number is r84.)

Speaking of build numbers, does the dispatcher/RPC/system handle r84 clients (v1.1.3) differently than r77 clients (v1.1.1) ?

The update database schema process seems to need a lot of memory on large-cache clients, that I needed to use -Xmx512m temporarily to get pass the process. No big issue afterwards though.

CODE

2013-12-14T04:32:13Z [info] CacheHandler: Initializing database tables...
2013-12-14T04:32:18Z [info] Updating database schema to r81...
Exception in thread "Thread-0" 2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)} java.lang.OutOfMemoryError: Java heap space
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at org.sqlite.NativeDB.column_text(Native Method)
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at org.sqlite.RS.getString(RS.java:313)
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at org.hath.base.CacheHandler.initializeDatabase(CacheHandler.java:169)
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at org.hath.base.CacheHandler.<init>(CacheHandler.java:93)
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at org.hath.base.HentaiAtHomeClient.run(HentaiAtHomeClient.java:122)
2013-12-14T04:32:21Z [ERR] {java.lang.Throwable$WrappedPrintStream.println(Unknown Source)}     at java.lang.Thread.run(Unknown Source)

Speaking of build numbers, does the dispatcher/RPC/system handle r84 clients (v1.1.3) differently than r77 clients (v1.1.1) ?

No. The last change was at r76, with the new testing mechanics.

The update database schema process seems to need a lot of memory on large-cache clients, that I needed to use -Xmx512m temporarily to get pass the process. No big issue afterwards though.

It could indeed be an issue on clients with a very large cache. Though, you could just delete the database and let it rebuild.

Client seems to be slowly losing trust again. It seems to have started after I switched to 1.1.3. As previous, I'll edit the post after some time to see if it's just me, or if it's actually dropping. Current trust is 850, down from ~930 before I switched, about 6.5 hours ago.

Edit: 1/2 hour later, it's holding at 853. Maybe that's my stable trust level. I'll continue monitoring.

Edit 2: Almost 1 hour later. Trust at 854, so it's stable now. Thanks for your hard work, Tenboro.

This post has been edited by Valkrey: Dec 14 2013, 16:32

No. The last change was at r76, with the new testing mechanics.

OK, thanks.

About the new threaded tests, is it normal that my only client that supports them is never requested to test other clients that way ? Also, this client is only "threaded" tested from time to time by a unique other client ... but both clients are on the same network (same hoster, different DCs which are connected though a direct F/O link).

This post has been edited by Hairs Fan: Dec 14 2013, 20:25

About the new threaded tests, is it normal that my only client that supports them is never requested to test other clients that way ? Also, this client is only "threaded" tested from time to time by a unique other client ... but both clients are on the same network (same hoster, different DCs which are connected though a direct F/O link).

Clients that frequently fail other clients eventually get suspended as testers for long periods of time, and your clients seem to be among those. It's not all that uncommon. (About 240 of the 1739 clients that are active right now are disqualified.)

After upgrading to 1.1.3 from previous version my quality seems to be getting lower and lower (usually it is at ~10000), now it reached 3913 in a day of running new beta (trust is at 1000)

This post has been edited by Owyn: Dec 15 2013, 19:13

After upgrading to 1.1.3 from previous version my quality seems to be getting lower and lower (usually it is at ~10000), now it reached 3913 in a day of running new beta (trust is at 1000)

Hm. I don't think that would be related, on average the quality is higher for those who run the beta branch. But let me know if it doesn't recover.