Version 150

Name
Email
Subject
Comment *
File	Select/drop/paste files here
* = required field	[▶ Show post options & limits] Confused? See the FAQ.

Embed	(replaces files and can be used instead)
Options	Do not bump (you can also write sage in the email field) Spoiler images (this replaces the thumbnails of your images with question marks)
Password	(For file and post deletion.)
Allowed file types: jpg, jpeg, gif, png, webm, mp4, swf, pdf Max filesize is 8 MB. Max image dimensions are 10000 x 10000. You may upload 1 per post.

YouTube embed. Click thumbnail to play.

Version 150 hydrus_dev ## Board Owner 03/18/15 (Wed) 22:20:19 No.470

win32
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v150/Hydrus.Network.150.-.Win32.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v150/Hydrus.Network.150.-.Win32.-.Installer.exe
os x
app: https://github.com/hydrusnetwork/hydrus/releases/download/v150/Hydrus.Network.150.-.OS.X.-.App.dmg
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v150/Hydrus.Network.150.-.OS.X.-.Extract.only.tar.gz
linux
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v150/Hydrus.Network.150.-.Linux.-.Executable.tar.gz
source
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v150.tar.gz

I had a very good week, overall. Building on the bit of work I fit in in the week before, I mostly fixed and improved things, and did a lot of code cleanup. Most importantly, I think I have fixed the problem of slow tag update processing.

tag update processing

I have added a 'speed mode' for repository update processing–it will kick in when the client thinks it is idle, which by default means after half an hour of not opening dialogs or looking at images. This speed mode will use a lot more resources than usual, but in turn will make the gui extremely laggy (hence why it only kicks in when you aren't doing anything). It processes tags about four times faster than normal, meaning about 3-4 million mappings per hour. Given that a few months ago, we were at something like 100,000 per hour, I am very pleased with this progress.

On a normal PC, and assuming the user lets the client alone to get on with it, syncing my entire public tag repository should now take about 2.5-3 hours. 4 hours was my aim, so I am content that this problem is no longer a problem. As tag repositories break ten or twenty or fifty million mappings, and so the clients' sync time slows even further, I will work on this problem more, but for now, the biggest bottleneck in update processing is inefficient use of bandwidth and laggy YAML parsing.

serious gallery downloader problem fixed

I have fixed a serious gui-lockup that no one has reported but blew up in my testing today. I'm hoping I only exposed it in this week's work, but if your client ever locks up completely just as a new downloaded image was fading in, that problem is fixed in this version, so make sure to update.

full list

- added an 'idle' updating processing mode that churns through tags four times faster but makes gui laggy. it will kick in whenever you haven't done anything in thirty minutes
- improved some gallery downloader status texts
- gallery downloader will no longer wait 5 secs before fetching first page of urls
- fixed a critical race condition that had a chance of causing complete and unrecoverable gui freeze in the gallery downloader code
- fixed rendering of some bizarro pngs that CV couldn't understand
- fixed tag parent management for admin users
- fixed up some tag parent dialog code
- tag sibling dialog now accepts single reasons for multiple pairs, like the tag parent dialog
- improved error state on rendering video that reports resolution of 0x0
- removed looping error reporting on certain static image rendering errors
- fixed an error when some thumbs were 'collected' while fading in
- tagboxes now select on home/end and support numpad versions of page up/down
- fixed a radio button initialisation bug
- boosted the initial size of the 'set default advanced tag options' dialog so the collapsible pane is more visibile
- silenced a upnp error when external ip can't be parsed
- reduced some tag dialog previous/next button lag
- general code cleanup and refactorisation
- gui flag refactorisation and unification
- refactorisation of most non-constant stuff from constants files
- refactorisations of media mixins class in prep for a general rewrite of that code
- improved client initialisation of default options, boorus, and imageboards

next week

Now update processing time is less of a concern, I am free to choose another big thing to work on. Someone mentioned a booru API, so I think I will look at that, to make booru processing more efficient and polite (atm, booru stuff works by parsing the gallery pages' html, which is not ideal). I also have the usual ton of issues to deal with and code to clean up.

Anonymous 03/19/15 (Thu) 23:24:48 No.481

File: 1426807488029.png (80.37 KB, 1015x830, 203:166, Capture.PNG)

When I go to the "add tags before importing local tag dialog the screen is blank like in the picture. After that the options menus don't work at all until I exit and restart the client.

Anonymous 03/19/15 (Thu) 23:25:33 No.482

File: 1426807533290.png (225.88 KB, 1105x1199, 1105:1199, Capture.PNG)

Corrupt options menu

hydrus_dev ## Board Owner 03/21/15 (Sat) 19:55:50 No.496

File: 1426967750803.jpg (112.25 KB, 891x1201, 891:1201, e6f74ffc17bb9a7f4fc2549792….jpg)

>>481
>>482

This is very strange–I am sorry you are having the problem.

Are you a long time user? Was this all working fine in v149? Have you ever had something like this happen before?

Are you using any graphical managers (like WindowBlinds) to alter the way windows draws its windows or widgets?

If you resize those faulty dialogs, do the controls flicker at all, or pop up instantly?

Do these dialogs ever show correctly? Is there a particular one, or a particular action that will reliably and repeatably break them subsequently?

What about double-nested lists, like in services->manage imageboards or services->manage services? Do they show up like normal when the others break? Do they break differently?

If you check your install_dir/logs/client.log file and scroll right down to the bottom, are there any errors that seem like they might be to do with this? You can email me your logs file if you like, or a selection from it, or throw it up on pastebin. Careful with making too much public, though, as there may be identifying information.

Thank you!

Anonymous 03/22/15 (Sun) 02:52:41 No.504

File: 1426992760702.png (237.32 KB, 1210x1059, 1210:1059, Capture2.PNG)

>>496

I've been using Hydrus since v141. v149 seems to work fine in that menu, so I just downgraded for the moment.

Windows 7 x64, nothing special for the window manager.

If I resize the corrupt options menu, the options sometimes appear at random height like in the picture.

On another install, I noticed the "add tags before importing" page worked as long as local tags were the only tag repository in there. It only broke after I added a remote repository.

Anonymous 03/22/15 (Sun) 07:18:08 No.507

I have the same issue.

Once you have triggered the problem, it also affects the manage tags page.

But if you increase the vertically size of the manage tags window you can see the missing ui elements at the bottom of the window.

Anonymous 03/23/15 (Mon) 21:35:16 No.519

first time using hydrus client so maybe I am just doing something wrong. But I have added some 1k images and by using the (out of date but still sufficient) help pages I have used your tag repository (not the file one) and it went through some 1040 updates or whatever.

The problem arises when I search for, well, any tag from the repository (or even the default ones like image size). The program locks up and no longer responds (Not Responding).

anyone got a fix for me? or tell me what I am doing wrong….

hydrus_dev ## Board Owner 03/24/15 (Tue) 21:56:19 No.523

File: 1427234179655.jpg (101.63 KB, 652x960, 163:240, 07159f92d3e9f077390022d7a0….jpg)

>>504
>>507

Sorry guys, I got swamped with other things and didn't get to your problem this week. I will make sure to do it first thing next week. If I can't easily figure out what is going on, I might make some debug builds if you don't mind running them, just to test what might be wrong. I'll make updates in this thread.

>>519

I'm sorry you are having trouble. If you don't mind answering:

What OS are you using?
How full is the hard drive hydrus is running on?
Is the hard drive an HDD or an SSD?
Is your computer a laptop or a PC?
How old is your computer?
If you boot the client and search for 'system:limit=10', does it still lock up?
If you search for 'system:everything', does it still lock up?
If you search for something that shouldn't have any results, like 'system:size>1000MB', does it still lock up?
In the bottom right hand corner of the program, does it say 'db locked' often?
Does it ever recover from locking up? Even, say, after five minutes?
If you go services->review services, does it take a while to load? How long, approximately, or does it completely lock up again?
If you go database->vacuum (this will take a few minutes, during which time your gui will freeze), does that fix anything?

Thank you!

hydrus_dev ## Board Owner 03/25/15 (Wed) 21:17:01 No.529

>>504
>>507

While building the release today, I reproduced this by accident. I looked into it real quick, and I have made an ugly fix for it just now. It will be in the release out in a couple hours; please let me know if you still get the problem!