hydrusnetwork/hydrus v643

Version 643

on GitHub

future build

• I am making another future build this week. This is a special build with new libraries that I would like advanced users to test out so I know they are safe to fold into the normal release.
• if you are experienced and would like to help me, please check it out: https://github.com/hydrusnetwork/hydrus/releases/tag/v643-future-01
• In my tests, neither of these required a clean install. Linux users might like to do one anyway, since this week is a big shift for them, particularly if it has been a while or you are on an odd flavour
• the specific changes this week are--
• Linux built runner from Ubuntu 22.04 to Ubuntu 24.04
• Linux built mpv from libmpv1 to libmpv2
• Windows built sqlite from 3.50.1 to 3.50.4
• opencv-python-headless from 4.10.0.84 to 4.11.0.86
• PySide6 from 6.8.2.1 to 6.8.3
• I was going to do dateparser 1.2.1 to 1.2.2, but there was a pyinstaller problem. we'll try again another time

misc

• animated jxl is now supported! as previously, hydrus handles this with a new 'animated jxl' filetype. mpv wasn't super happy with the jxl files I was playing with, so I'm only enabling this for the hydrus ffmpeg-powered native viewer for now, like animated webp. all existing jxls will be queued for a rescan on update, so you don't have to do anything. performance is not amazing, and there's no variable frame rate support, and I'm afraid the tests here add yet more time to the jxl import process, but it does work. I'll keep checking in future for nicer (native Pillow etc..) solutions here. I looked at parsing jxls manually, like we do for quick png/apng differentiation and parsing num_frames etc..., but jxl appears to be pretty wewmode internally (issue #1881)
• in the 'edit times' dialog, when editing an individual time, the 'paste' button now eats milliseconds correctly whether you post a raw timestamp like 1738783297.299 or a datestring like 2025-10-10T12:00:00.123+02:00 (issue #1884)
• the manage tags dialog has a new "deleted mappings" text-and-icon that appears below the paste/cog icons if there are deleted mappings. it'll say "3 deleted mappings" and show you an eye icon. click the eye to show/hide deleted mappings. this display setting is now remembered through dialog open/close and is no longer accessible through the cog menu. this is an experiment, and I am open to doing more display options here to finally get on top of some finicky workflows
• hitting 'show deleted' in the manage tags dialog now redraws the list immediately; previously, it wouldn't actually show until the list incidentally repainted itself otherwise, e.g. after a click
• 403 (forbidden), and 509, 529, 502, and 522 network errors (bandwidth and gateway problems) no longer spam the log with so much server response text
• fixed some Qt crashes related to PDF import
• fixed some Qt crashes related to SVG import
• updated the 'eye' icon to svg. I'm actually happy with it; I even added a caruncle
• added an 'eye_closed' svg icon
• I think I figured out the 'list of tags in the media viewer background has a different line height than the hover window' bug that hit some Linux flavours

duplicates

• by default, the client now searches for potential duplicates in normal time. this code now has such low per-file overhead that it isn't a bother
• 'potential duplicate pairs search' panels, such as in the duplicate page or the auto-resolution rule edit panel, now, by default, state an estimate of the matching count once they have found 1,000 matches. for instance, it might say "513,547 pairs; ~210,000 match". it makes the estimate once it has found 1,000 matches and obviously stops working a lot faster this way. a new cog button let's you switch back to the old 'always precise' behaviour. let me know how this feels with IRL data!
• I examined making 'apply alternates/false positive to many files at once' work in a sane way (atm it applies to all internal pair combinations, so millions of relationships when you reach a single group of thousands of files), and it is not possible with the current file relationship storage. one solution I had discussed with users as a mid-way stopgap might have legs, but I think it is still insufficient. I have made a plan to improve this but will not do it in the push to finish auto-resolution. sounds like 2026

duplicates auto-resolution

• added a 'AND' comparator type. this works like the OR one and allows you to clause a bunch of different comparator types together within a OR collection. I know some users have wanted to try something like (A filesize > B AND A imported earlier B) OR (A filesize > 1.2x B AND A imported after B) within the same expensive 'visual duplicates' rule. I think it is a little awkward, but have a think and see how it goes
• some more small tweaks for the suggested rules--
  • the 'visually similar pairs' rule now has A filesize > B rather than >= because the dialog won't ok without a definitive way to arrange A and B, hahaha. since a non-pixel-dupe visually similar pair of exactly the same size is unlikely, I'm fine not catching them here
  • the 'pixel-perfect pairs' rule now has ( A filesize > B ) OR ( A filesize = B AND A imported earlier B ). previously, it just had A filesize > B. I have discovered that pixel perfect duplicates of exactly equal filesize are not uncommon (I particularly encountered it with some imagemagick resizes of the same original files done several years apart on different OSes, where I assume the only difference is some version enum in the file header), so I wanted a tie-breaker clause for them
• the auto-resolution help is now updated to talk about this
• an empty OR or AND comparator now gives an appropriate summary string
• I explored making resolution rules work on their queues in a more random order, but I backed off when I couldn't make it fast. there's a way to make this happen, but not a simple one, so I'll back burner it for now. the rules pull pairs in an order according to SQLite's whim, which often produces pairs featuring the same file in a row, which you may have seen in the pending action log. this is fine in some ways but it wasn't intentional and does give some minor headaches. unfortunately the most important thing about this guy is he runs with very low per-file overhead, so I'll leave things as they are for now

mpv

• the new mpv interface is now turned on for all users. thanks to those who tested different situations for me. you should notice that mpv is slightly less laggy and generally more stable
• if you have a very old version of mpv and video suddenly throws a bunch of errors about command_async, please check options->media playback->LEGACY DEBUG: Use legacy mpv communication method
• I also updated this new code to be more polite about seek-scrubbing. if a new seek command comes in while a previous seek command is still working, it now waits until mpv is done and and then sends the most recent seek command received. it is now quite difficult to produce the 'too many events queued' error by scrubbing
• as the 'too many events queued' error is rare and no longer big deal, it'll no longer spam to the log
• I experimented with 'do a faster keyframe seek while dragging, and only an exact seek when mouse down/up', but it felt pretty bad with the low-latency keyframe seek caret bouncing around as you dragged, sometimes to the start of the video. I'd rather spend the CPU and have a nice experience
• added 'allow crashy files in mpv' to help->debug->debug modes. this disables the handler that would catch problems here and allows loading of files previously put on the blacklist. I notice that with the new async interface, I can't really get mpv to crash any more and while even totally whack files will spam the log, visually they'll just flitter between the first two frames or whatever. maybe we'll make this guy less strict in future

boring stuff

• tweaked some database migration help
• clarified in the options that the 'idle mouse' setting is global, not just mouse over the hydrus window
• cleaned up some canvas painter handling to do nicer save/restore within draw methods