[X] My Assistant

Linux is tricky since there's no such thing as a "standard" GUI text editor

In theory you should be able to do:

CODE

xdg-open <log>

If that fails then

CODE

xterm -e /usr/bin/bash -c vi <log>

This will work on all user-friendly distros. And, if someone uses a real linux, he should be able to find the log himself.

Sounds awesome, though I'll wait with update if you say 1.3 is a bit experimental still.

Awesome improvement Tenboro! galleryinfo.txt is back too!!!
THANK YOU!!!
I'll see if my other issues also get solved (I hope hope hope...)

Well, that's certainly a welcome change for many other than myself I'm sure, thank you Tenboro.

Holy balls though, the initial startup takes so long, though I suppose that might be a happy problem.

This post has been edited by zxwecrt: Oct 4 2016, 15:33

Sounds awesome, though I'll wait with update if you say 1.3 is a bit experimental still.

It's experimental in the sense that a lot of the core code was rewritten. Most of the complex changes have been live on our test servers for almost a month (since September 8th), but that's not a lot compared to the 5+ years of the old code.

By now there are 96 clients running 1.3.0, and the only issue that's been discovered (or, at least, reported) was a minor server-side issue with the new downloader, which has been fixed.

2 Things for now:

Is there a way to select which files to download from a gallery? For example:
Only download images: 5, 422, 827, 828, 950, 975 and 1673 on a gallery (and pay in GP accordingly).

Is there a way to keep a backup or sorts of the hathdl file in case something "bad" happens in order to reload the files (even if manually) sometime later?

Barring any bugs, this release should be far more light-weight than 1.2.6, with reduced CPU usage, 1/4th to 1/2th of the RAM requirements, and a small fraction of the disk I/O for bookkeeping purposes.

So does this mean that for a given amount of RAM, a client running 1.3 would be able to cache 2-4x as much content in memory?

Is there a way to select which files to download from a gallery? For example:
Only download images: 5, 422, 827, 828, 950, 975 and 1673 on a gallery (and pay in GP accordingly).

Not without modifying the client, and even then it wouldn't get a "discount".

Is there a way to keep a backup or sorts of the hathdl file in case something "bad" happens in order to reload the files (even if manually) sometime later?

Not really. Even if you modified the client to add some kind of save/load capability for the HathDL descriptors, the dlfetch API call it uses to get the links to download the actual file would not work unless you have a valid session for the download.

So does this mean that for a given amount of RAM, a client running 1.3 would be able to cache 2-4x as much content in memory?

Well, the OS certainly would be able to use the saved RAM for its disk cache instead, but it would only be 2-4x as much if you were so pressed for RAM that this increases your free RAM by 2-4x.

Could the website be updated so that this could be found a little faster and easier ? i had to google a little bit till i was able to find where to download the 1.3 H@H

h t t p : / / g . e - h e n t a i . o r g / h e n t a i a t h o m e . p h p

thanks

sorry for the spaces but i got a error saying i cant post a link as my first post because of spam.. and since this is not spam i added a lot of spaces.

i had to google a little bit till i was able to find where to download the 1.3 H@H

It's right in the OP...

Could the website be updated so that this could be found a little faster and easier ?

The 1.3 branch is experimental, so it won't be posted to the site or trigger the upgrade message on 1.2 clients until it's considered stable enough to graduate as 1.4 or 2.0 or whatever.

Well, the OS certainly would be able to use the saved RAM for its disk cache instead, but it would only be 2-4x as much if you were so pressed for RAM that this increases your free RAM by 2-4x.

Slightly disappointing, but makes sense. I'll just add more ram then.

Upgraded, and my disk cache just keep growing, the free cache size is -8.3GB so far.
Tried restarting the client, didn't work. (⋟﹏⋞)

Not without modifying the client, and even then it wouldn't get a "discount".

That's sad. I liked editing the hathdl file to filter galleries to only the files I want. Specially useful in artist galleries and image galleries.
It's at this time I wish I knew how to program.

Not really. Even if you modified the client to add some kind of save/load capability for the HathDL descriptors, the dlfetch API call it uses to get the links to download the actual file would not work unless you have a valid session for the download.

Then load may be useless... If I had saving joined with the above. I could manually get all I had got back in case I lose them without having to navigate in all the website.
Saving is still useful as a database.

This post has been edited by Jay Low: Oct 4 2016, 08:35

Upgraded, and my disk cache just keep growing, the free cache size is -8.3GB so far.
Tried restarting the client, didn't work. (⋟﹏⋞)

Could you upload your log_out file somewhere and send me the link?

Edit: For very high traffic clients, it's possible that the new cache pruner is not sufficiently aggressive. Generally it will work better the longer you've been running 1.3, but try downloading this version and see if that fixes it for you. (If nothing else, it will prune your cache down to size at startup if it's oversize.)

Edit 2: Actually, grab this version instead. It has a new automatic aggression adjustment for the pruning mechanism, which should solve all issues like that.

Hi, thanks for the update. But it seems i can't resize my window now (long sentences are cut)

- (GUI) The logpane was tweaked to avoid gobbling up massive amounts of RAM when the log was scrolling quickly. To enable this, the H@H window is now fixed size.

What are the chances to get an auto-updater?

Could you upload your log_out file somewhere and send me the link?

Edit: For very high traffic clients, it's possible that the new cache pruner is not sufficiently aggressive. Generally it will work better the longer you've been running 1.3, but try downloading this version and see if that fixes it for you. (If nothing else, it will prune your cache down to size at startup if it's oversize.)

Edit 2: Actually, grab this version instead. It has a new automatic aggression adjustment for the pruning mechanism, which should solve all issues like that.

It works! Problem solved, thanks(ᗒᗨᗕ)

1.3.1 was released, which fixes the following issues:

- Some very high-traffic clients (3-400+ hitrate) experienced a situation where the file pruning mechanism could fall behind and make the cache grow past its limit. The cache handler will now automatically make the pruning mechanism more aggressive if it is in danger of exceeding the cache limit.

- If the cache is above the limit at startup, the cache handler will now loop the pruning mechanism during initialization until the cache is below the current limit.

- The GUI can again be resized. Note that increasing the window size will somewhat increase how much RAM the GUI consumes. Making the window wider will not reveal full cache lines that were written before being extended, to avoid having to store arbitrarily long log lines.

You do not have to update unless you're having issues with the cache growing beyond its limit, or you want the resizeable GUI back. Download links in OP have been updated.