https://www.youtube.com/watch?v=OQM8AIbFW4g windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v346/Hydrus.Network.346.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v346/Hydrus.Network.346.-.Windows.-.Installer.exe os x app: https://github.com/hydrusnetwork/hydrus/releases/download/v346/Hydrus.Network.346.-.OS.X.-.App.dmg linux tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v346/Hydrus.Network.346.-.Linux.-.Executable.tar.gz source tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v346.tar.gz I had a great week. There's a bunch of fixes and thumbnail improvements, a more powerful manage urls dialog, and a prototype OR search to try out. thumbnails Last week's big thumbnail change seems to have gone fairly well overall. There do not seem to be any huge errors anywhere, and the simpler file system and code is great, but I was annoyed by how slow certain regeneration scenarios turned out to be, and how some thumbnail resizes were a bit blurry. To address this, this week I have cleaned and improved a bunch of thumbnail loading code. It was much nicer to do now I only have one thumbnail file to juggle. Thumbnails should now be a less blurry when they scale up, and they should generally load a bit faster whenever a lot of regenerations need to be done (you should notice CPU-expensive video thumbs load last of all, while easy ones like pdfs and pictures should come in first). I was also annoyed that even small changes in desired thumbnail size would force a complete regen, which was particularly laggy when scaling up. So, to smooth out the loading time when you have recently changed the desired thumbnail resolution, I have added an experimental regeneration throttle. When the difference between what is available and what is desired is just a few pixels (and so a scale will not be too fuzzy), rather than regenerating from source, the client will now mostly just scale up or down what it already has. When the difference is great, it is more worth spending the CPU on a full regeneration to get a clear thumbnail, so it will regenerate more often. It still eventually regenerates everything, but when the difference is slight, the real workload will be spread over several loads. For some example numbers, if the thumb on your disk is 120x120 and your options want 125x125, the client will expensively regenerate from source only about 29% of the time and scale up the original 120x120 about 71% of the time. But 120x120 vs a desired 250x250 will regenerate/rescale about 84%/12% of the time. This is a big experiment, but I am generally pleased with it: it does speed up thumbnail load in many situations that were previously needlessly slow, and the relative fuzziness is generally not a noticeable problem. I hacked the percentage ratios out of some statistical polling that I can definitely tune in future, so please let me know if your situation produces too many very fuzzy thumbs. Also, if you are in 'advanced mode', the thumbnail right-click menu now has more 'regenerate' options: as well as doing a complete file reparse and thumb regen, you can now choose to just regenerate thumbnails or only regenerate thumbs if their size is wrong. If you are an advanced user, please feel free to play with these new commands, particularly if you notice fuzzy thumbs from the throttle above, and let me know how it goes. I expect to do more work on thumbs in the coming weeks. As well as tuning the new regeneration throttle, I would like to expand the new database-level thumbnail regeneration modes to work during maintenance time. I have long planned a 'file reparse' db maintenance mode so I can finally fix all the ancient mistaken animation frame counts and mime mismatches like apngs/pngs and mkvs/webms, and now this same maintenance command can also just do thumbs, I would love to let users say 'please regen all thumbs that are the wrong size in the background during idle time, no more than 20mins/day'. There's no reason why this stuff should be only on command for advanced users, so now I need to build the maintenance structure for it. I'd also like to extend the current thumbnail location override under migrate database to work just like the files, so you can balance thumbnails over multiple weighted locations. Linux and OS X users: You may not have received an error, but it is decently likely that last week's 'rxx' folder delete did not work for you. This was due to a permissions-setting mistake on my end. I have fixed this permissions code, and on this 346 update, if you still have some rxx folders in your db, the client will attempt to re-do the delete. If it wants to do this, it will give you another popup message as you update, informing you of the situation before it goes ahead. or search Several things came together this week, and I managed to get an early prototype of OR search working completely. I am keen to get users' thoughts on how to finish it off. To start an OR search, hold down shift when you enter a tag in a search page. Rather than adding this tag to a search, it will now place it in a new box just above the input box. Further shift-enter actions will increase the OR 'chain', making 'tag A OR tag B OR tag c', and a final non-shift enter will cap the chain and send the OR search predicate up to the main search. It works! You can even add system predicates! However, this entry method is not finished. Have a play with it and you will see what I mean. There is no neat way to cap off an OR chain early (i.e. without typing anything new: if you hit a bare enter on it, you'll get system:everything or system:inbox on the end), nor to 'go back one' if you put the wrong tag in. Also, system predicates that need additional panel infomation before 'going through' do not hold on to the shift status. Beyond the bugs, I am interested in what you would like for the workflow here–would you rather the OR-chain under creation be inserted as the top item in the list below, rather than in the new box above? Should it be highlighted as under construction somehow? Should it have a dangling OR while under construction, such as 'blue eyes OR green eyes OR' rather than 'blue eyes OR green eyes'? How should it be cancelled, or undone a step? What would be the best way to say 'ok, I have A OR B OR C entered, and I don't have a D to add, so I want to enter what I have now'? the rest I made two more stupid errors last week–one that draws white frames over animations on certain media update events, and one that occaisonally set the 'include current tags' value on search pages to 'false' on reloads. I have fixed both of these issues, and as a one-time for this update, all 'include current tags' values are forced back to true. I am sorry for the inconvenience here. The white frame stuff drove me nuts all week. Beyond that, I extended the 'manage urls' dialog to support multiple thumbnail selections, which allows for easy mass-deletion of bad URLs. The URL list on this dialog also now supports multi-selection and accepts the delete key. It also supports adding URLs to multiple files, but when opened on multiple files it presents a little red-text warning to remind you that adding a URL to multiple files only makes sense for gallery URLs. I expect to do a little more work on this in future, cleaning the workflow a little more and detecting the url class of urls you attempt to add to multiple files, specifically testing what is and is not appropriate to add. In any case, like everything else this week, please give it ago and let me know how it works for you! Also, the 'move files now' button on database->migrate database now lets you limit the max time it will run to 10/30/60 minutes! This is a nice stopgap if you, say, have 600,000 thumbnails to move and don't want to do it all at once. full list - or search:

[Expand Post]

- extended the search predicate object to handle more OR stuff - extended the tag list to handle list objects that have multiple colours - extended the new OR search predicate to report multiple text-snippet-and-colour pairs based on sub-predicates - extended tag search input to handle prototype OR predicate creation–hold shift when you enter the tag, and it'll start an OR chain. shift-enter continues the chain, enter alone completes it - fleshed out the predicate unit tests to cover more of this - wrote unit tests for OR search predicates. it seems good! - improved some search logic to apply system preds better in certain edge cases and spend less CPU on OR-search-only searches - . - thumbnails: - thumbnails will now queue for load in a more intelligent order based on estimated difficulty to regenerate, which will tend to put more thumbs on screen faster - the decision to regenerate a thumbnail from source is now tempered by how different the current thumbnail is from what is desired–the more similar the two sizes, the more (randomly) likely the client will decide to just use the current (resized) this time. this smooths out change-lag while limiting the number of really fuzzy thumbs you get. feedback on how this works IRL would be appreciated–it uses some voodoo distribution polling to figure it out, which I can definitely tweak - improved visual quality of thumbnail scale-up optimisations - fixed an issue where a multipage thumbnail grid would incorrectly recalculate the new virtual height after a thumbnail size change event, leading to a bit of invalid extra scrollspace (with noclip rendering errors) at the bottom - the thumbnail right-click menu's reparse files entry is now extended to a new 'regenerate' submenu with three options: reparse file and regen thumbs (the old action), force regen thumbs, and regen thumbs if wrong size! - the new 'regen if thumbs wrong size' action sends how many thumbs needed resize up to the popup window, as well - moved some old thumbnail regen code responsibility out of the db and into the files manager - cleaned out some old redundant file/thumbnail code - cleaned and refactored a bunch of general image handling and resizing code - . - the rest: - fixed some bad serialisation code that was making file search objects set their 'include current tags' value to false/true on interleaving loads. on this update, all 'include current tags' values are blanket reset to true - fixed an issue that was drawing animation canvases pure white on various media update events - extended manage urls dialog to support multiple files when launched from a selection of thumbnails. there is a warning in this case, noting that only gallery-style urls are appropriate to be added to multiple files - manage urls dialog now supports multiple selections, including shift-select, and accepts delete key presses for easy mass deletion - when you ask the database migration dialog to move some files, it now pops up a confirmation dialog that also asks if you would like to limit the max time for the job as 10, 30, or 60 minutes - improved file permission setting code across the program to be more sensible for non-Windows - if you are a non-Windows user and were hit with directory permission problems last week on the thumbnail update–which resulted in the rxx directories not being deleted–the update this week will attempt to do the delete again, this time correcting the now missing execute permission bit. if it finds outstanding rxx directories to delete, it will give a popup beforehand summarising the situation and giving you a chance to bail out - fixed yet another problem that was stopping client api url requests from finding the correct page by name - when a client api url request includes fixed tags, these tags should now propagate in all scenarios where the single url produces multiple files - updated sqlite dll and console for windows - misc fixes and cleanup next week Next week is a 'cleanup' week. I'll keep chipping away at the listctrl rewrite and other boring jobs, and I'll see if I can finish up the OR search entry workflow in a sane way. Thanks everyone!