windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v411/Hydrus.Network.411.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v411/Hydrus.Network.411.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v411/Hydrus.Network.411.-.macOS.-.App.dmg
linux
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v411/Hydrus.Network.411.-.Linux.-.Executable.tar.gz
source
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v411.tar.gz
I had a good week. The siblings work is complete.
siblings
The last areas that used the old siblings systems are now migrated to the new fast cache. The 'loading tag siblings' step of client boot, which for PTR users could be several seconds of work, is no longer needed!
These last parts are all user-facing UI code. Mostly tag autocomplete behaviour and the 'will display as' labels you see in tag edit contexts. Everything now goes through the database, and all in a nice asynchronous way, so (fingers crossed) it will not add noticeable lag.
As I unified code here and moved to nicer logic, I was able to clean up some behaviour. Matching siblings based on what you type (for instance, if you have 'lotr' siblinged to 'series:lord of the rings', text-matching the latter even if you type the former) should be cleaner and more reliable. Also the 'will display as' labels should appear in all the tag suggestion columns, and some other 'edit tag' places.
There is still more I could do here. Using 'manage tags' on thousands of files at once can be a bit laggy, both in working and once you hit apply, and I could make '(will display as xxx)' labels colour according to the xxx namespace to make them 'pop' a bit, and I would still like to ultimately replace the individual 'will display as' labels with something neater for workflow. But I have been focusing on siblings for more than a month. Now the main virtualisation and boot lag elimination objectives are done, I should move on to other work.
If you have been waiting to update from 407, this is a fine week to do it. There will still be a whack of update CPU if you sync to the PTR, but on an SSD it shouldn't be more than a one-time shot of 10-30 minutes.
full list
- misc:
- fixed the 'system:(like/dislike) rating = x' search predicate string, which was saying 'unknown' rather than 'like/dislike' in several cases
- fixed a 'current_count' error in the new file search optimisation code for tag searches where the tag did not exist for any files in the domain (i.e. autocomplete count=0). thank you to users for helpful reports here
- fixed the recent file search optimisation code to handle 'system:time imported' when it was mixed with tags or search predicates that would pre-populate the query file pool with file domain cross-referenced files. sorry for the trouble!
- the forced delay overhead for table analysis is reduced from 0.1s to 0.02s. whenever many mostly empty tables need to be analyzed (like on first boot shutdown, when it is usually 100+ tables), it now zips by
- .
- siblings/tag improvements:
- typing a shorthand sibling like 'lotr' into an 'all known tags' 'read' autocomplete - like on a default search page - now reliably discovers and matches text entry to ideal sibling results like 'series:lord of the rings'. this was previously buggy and unreliable–it now allows the match using better db knowledge, even when the merged 'all known tags' services involved disagree on siblings
- when typing tags into a 'searching immediately' page that has media, the autocomplete count results that only refer to that media will now match shorthand sibling inputs to the ideal result. media-populated tag search now takes a little bump of extra CPU to fetch results (they are now passed through the db to get nice siblings info), so it is also cached for the duration of your typing (previously, the counts were re-computed on every new keystroke, so this should be significantly smoother to work with on large pages even if that first keystroke takes a moment to give results)
- when typing into a 'write' autocomplete, like in manage tags, the process that promotes the entry text and known siblings to that entry and a potential ideal sibling result to the top of the list is now more sane. it now also only uses results with nonzero count. we'll see how this last change works out IRL
- when typing into a 'read' or 'write' autocomplete, the pre-search tag insert no longer has sibling insertion/swapping. it was unreliable before, with weird sibling-swapping in the short moment before real results returned. if you have slow results and often quick-add tags into search pages or manage tags, let me know how this works for you
- the 'additional tags' tag input dialog off the tag import options edit panel now shows the 'will display as' label
- the 'favourite', 'file lookup', and 'recent' tag suggestion panels now show the 'will display as' label
- the 'related' suggestion panel, which works on a slightly different system, now shows the 'will display as' label
- the 'tag suggestions' options panel's 'favourite tags' edit lookup and list now displays 'will display as' labels and correctly finds service-specific siblings in its results (e.g. you type 'lotr', it also finds 'series:lord of the rings')
- all autocomplete tag filtering should be just that little bit faster as you type
- filtering cached autocomplete results based on subsequent search text is now faster
- autocomplete inputs should no longer return 'ghost' results that have no current/pending count when one of the 'include current/pending' buttons is deactivated
- the new database autocomplete predicate generation routine now checks for 'cancel search' signals, saving CPU time as you type
- the slow 'regen chains' maintenance tasks now process sibling chains in random order, smoothing out the 500/100,000 progress label, which previously took about 80% of time on the first 20% of ids due to IRL tag distribution
- .
- the last UI-side siblings work is cleared:
- the UI-side tag siblings cache is no longer used. the sometimes multi-second 'loading tag siblings' step of boot no longer happens!
- media autocomplete fetches are now asynchronously populated with siblings data via the db
- the exact-match and sibling 'insert' predicates at the top of pre-load and post-load read and write autocompletes now rely exclusively on db data for sibling matching
- taglists now present 'will display as' labels asynchronously and are better about updating those labels when the list's underlying tag service changes
- the taglist right-click menu that shows siblings to copy now fetches that submenu's contents asynchronously from the database
- the test panel on a blacklisting tag filter now asynchronously fetches tag siblings to test against from the database
- the actual blacklist tag filter test now fetches tag siblings to test against from the database
- reworked my custom tag listbox to handle asynchronous text decoration, and unified sibling decoration for media taglists and string taglists
- updated my old async updater class to be more flexible for different job types, and cleaned the code that already used it
- wrote a simple class for one-shot async jobs
- wrote a simple db lookup for UI-side tag sibling chain members
- wrote a simple db lookup for UI-side tag ideal siblings
- bunch of misc sibling, db, and ui work and cleanup to make all this work
next week
I was going to go straight onto the parents database cache, which is basically a smaller repeat of this siblings work, but I think I will insert a couple of weeks of smaller work first. I'll actually catch up on github issues and also stop myself from going crazy.
I have two more big jobs for the year: this upcoming parents cache, and a network update iteration to improve client-repository communication and control. I'd like to have a new 'big job' poll up for Christmas.
