/hydrus/ - Hydrus Network

Archive for bug reports, feature requests, and other discussion for the hydrus network.

Index Catalog Archive Bottom Refresh
Name
Options
Subject
Message

Max message length: 12000

files

Max file size: 32.00 MB

Total max file size: 50.00 MB

Max files: 5

Supported file types: GIF, JPG, PNG, WebM, OGG, and more

E-mail
Password

(used to delete files and posts)

Misc

Remember to follow the Rules

The backup domains are located at 8chan.se and 8chan.cc. TOR access can be found here, or you can access the TOR portal from the clearnet at Redchannit 3.0.

US Election Thread

8chan.moe is a hobby project with no affiliation whatsoever to the administration of any other "8chan" site, past or present.

(11.01 KB 480x360 IPjvDE-rKo0.jpg)

Version 416 Anonymous 11/05/2020 (Thu) 00:05:25 Id: c72a54 No. 14895
https://www.youtube.com/watch?v=IPjvDE-rKo0 windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v416/Hydrus.Network.416.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v416/Hydrus.Network.416.-.Windows.-.Installer.exe macOS app: https://github.com/hydrusnetwork/hydrus/releases/download/v416/Hydrus.Network.416.-.macOS.-.App.dmg linux tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v416/Hydrus.Network.416.-.Linux.-.Executable.tar.gz source tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v416.tar.gz I had a great week catching up on a mix of smaller work. highlights The manage tags dialog is now more efficient at making changes for very large numbers of files. My test application of 6 tags to 10,000 files went from 52 seconds to 4.8! A variety of other tag presentation updates should also benefit from the optimisations here. I reworked my hacky multi-list sizing code. The various instances of the final column sizing weird should be much better. The horizontal scrollbar is enabled again. A new checkbox under options->files and trash now lets you prefix any copied hash with the hash type, like "md5:2496dabcbd69e3c56a5d8caabb7acde5". If you often paste hashes into boorus or other search engines that take this format, this should make it a bit quicker! I am rolling in default thread watchers for warosu, prolikewoah, and smuglo.li. Warosu seems to have some CloudFlare stuff going on, so your mileage may vary. full list - misc: - the new siblings and parents taglist menus now copy just the actual tag when you click, excluding the 'ideal/child/parent:' prefixes - added a checkbox to _options->files and trash_ that allows you to automatically prefix hashes copied to clipboard with their hash type in a booru-lookup friendly manner, such as "md5:2496dabcbd69e3c56a5d8caabb7acde5" - the media viewer now remembers if it was previously maximised when you set it to un-fullscreen (before, it would always restore-window-ise) - fixed the 'test address' button in _manage services_ for hydrus administration services - improved the 'add upnp mapping' error handling to better catch 'already mapped' error, with separate errors for redundant, already-on-but-wrong-port, and already-on-another-computer - improved error handling when saving objects to the database, particularly for encoding or giganto-size-session errors - rewrote my tag sibling lookup unit tests to deal with more situations - wrote similar fairly comprehensive tag parent lookup unit tests - . - new downloaders: - rolling in a user-created thread watcher for warosu. it may be CloudFlare hampered depending on your situation - rolling in a prolikewoah thread watcher - rolling in a smuglo.li thread watcher - . - multi-column lists: - spent a bunch of time cleaning out how I calculate multi-column list preferred initial width/preferred current width/minimum width, and made the final column more flexible in its resizing. instances of dialog suddenly getting gigantic because of a final column that wants to size itself at 1,000px should be completely gone, and lists that are shrunk due to non-last-column resizing will now adapt to this situation and not try to flex back to total initial width. - multi-column lists now have horizontal scrollbars again for those situations where the parent window is thinner than their (now better calculated) minimum size - improved the multi-column list num_rows height calculation, it should have less empty space at the bottom for lists that grow as items are entered into them (such as in the download pages) - . - manage tags megajob speedup: - sped up manage tags final application step when entering many tags for many thousands of files at once - optimised UI-side per-file tag cache (re)generation, reducing overhead and surplus work
[Expand Post]- granularised UI-side per-file tag cache (re)generation based on the four current tag display contexts–now, if a system (e.g. manage tags dialog) only needs storage tags, the different display tags do not need to be regenerated - optimised all tag filtering, which is also used in UI-side tag cache regen - overall, giganto manage tag dialog jobs should now be faster in several ways. on my dev machine, adding 6 tags to 10k reasonably tagged files went down from 52s to 4.8. even larger jobs will still need a lump of CPU time, but they should scale more efficiently (what was previously O( num_tag_changes x num_total_mappings ) is now O( num_total_mappings ), and better at that) - when a huge number of tags is added at once in the manage tags dialog, 'recent tags' is now populated more carefully next week I want to do more of this work, catching up on older items and things that have piled up in the past few weeks. There are eight weeks left in the year. I want to do one large round of network updates, but otherwise just more like this! I will be updating the 'network version' of hydrus next week, which will mean any client that talks to the PTR will need to update to keep syncing, or it will get a polite popup message telling them to. This will guarantee that all PTR clients will be on the new virtual sibling and parent caches, containing the problem of sibling and parent based surplus/faulty tags being uploaded. There should be another version update before the end of the year when I commit the planned network changes.
I accidentally put the 415 release links in here when I first uploaded, fixed now!
>>14895 >My test application of 6 tags to 10,000 files went from 52 seconds to 4.8! VERY big optimization, thank you dev! I did a lot of my preliminary mass tag-correcting last year and I had to do it in batches to keep everything from crashing and burning at the time, and still it hung a lot. Now that my duplicates are largely done with I've been going about my first serious attempt at comprehensively trimming down junk files. So far I've done a cursory run through tagless files for things to throw away, purged my lowest-quality source of files of all immediately obvious deletes, and now I just finished processing my 1280 smallest image files in batches of 64, deleting most of them. I've gone from around 2 saved per batch to around 12, so I'm getting to the end of that being practical. My next task after sorting my less-strict duplicates might be finally tackling the hellscape that is my tumblr imports, which in addition to being the worst leg of the pre-full-tagging-and-archival-process sweep of my db, will have a lot of things that need the tags fixed because I'm dumb and switched my methodology halfway through (and so did Tumblr, but at a different time, and so did Hydrus in a way). So this will definitely still be extremely useful to me because some of those tumblr image collections were giant. Also my backlog for downloading videos and importing them to Hydrus has moved from deleting the extra junk links in jDown to actually having no more drive space left until I watch/delete/keep/edit video clips. The ride never ends, but I have finally settled into a sustainable cruising velocity for now.
>>14903 Great, I am glad this will be working for you. I understand the manage tags dialog can still lag a bit on the final 'apply' step for very large changes, so I will look at that too soon, to spread the work out a bit.
I had a great week. I did a variety of small work, fixing bugs, adding new shortcuts, updating some libraries and downloaders, cleaning up old code and UI, and adding a couple of advanced features to the downloader system. The network version will go up tomorrow, which means clients will have to update if they want to keep syncing with the PTR. There is no need to rush, and no penalty if you delay–syncing will just pause until you update. The release should be as normal tomorrow.
>>14913 Thank you very much, this actually helps so much in downloading art. God bless you!


Forms
Delete
Report
Quick Reply