/hydrus/ - Version 382

Name
Options
Subject
Message	Max message length: 12000
files	Drag files here to upload or click here to select them 0.00 / 50.00 MB 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

Version 382 Anonymous 01/29/2020 (Wed) 23:20:19 Id: 2726aa No. 13580

https://www.youtube.com/watch?v=aZL4upd4QpI EDIT: Fixed Links windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v382/Hydrus.Network.382.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v382/Hydrus.Network.382.-.Windows.-.Installer.exe macOS app: https://github.com/hydrusnetwork/hydrus/releases/download/v382/Hydrus.Network.382.-.macOS.-.App.dmg linux tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v382/Hydrus.Network.382.-.Linux.-.Executable.tar.gz source tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v382.tar.gz I had a good but light week. MPV should be working better, and some of the recent UI animation flicker/jitter should be gone. mpv Introducing MPV added a weird bug–after the first time an mpv window was opened, the client would then in some cases fail to animate thumbnail fade or process certain intra-program events unless another event, such as a mouse move over the program, restarted the event loop. Some media viewer transitions have also had some single-frame flicker. I have banged my head at this problem for a couple of weeks now, thankfully improving some behind-the-scenes code along the way, but I could not find the full solution. As it happens, rolling Qt back to a slightly older version (5.14.0 to 5.13.0, for users running from source) seems to have completely fixed it. It could simply be a 'native window' bug in the new version of Qt, but at the moment I still suspect my mostly borked wx-code-trying-to-talk-to-Qt-code. Until I can clean that code up, I am happy to have this easier solution. I fixed a recent issue with the preview viewer not clearing out media correctly on page changes (which was particularly significant now we have audio) and also fixed an mpv crash for Linux/macOS users who happened to already have MPV available through their OS. Also, MPV is now configured to have a 'lighter touch' on filesystems, so if you have a client with a laggy file storage system (e.g. a very large client stored over a network share) and have experienced extreme latency when trying to open MPV, this situation should be much better. MPV should be fairly stable now, so my big remaining tasks are to get nicer volume controls and proper build support for Linux and macOS. MPV as a program relies on '.conf' files for most of its configuration. Hydrus now follows this format. If you have your own conf or otherwise would like to edit this, please check out the mpv.conf under install_dir/static/mpv-conf. If you have settings you think should be in the default for all users, let me know. I'll likely let you optionally override where hydrus looks for its conf (where it can't be accidentally overwritten on update) in future. the rest There are now a couple of user-created darkmode stylesheets in a default install, so the stylesheet section of options->style now has some entries for everyone. Feel free to check them out–there are still some colours in the client that are hardcoded like green/red button text and anything under options->colours, but I plan to move everything over to Qt in time. When you zoom out from a zoom that makes the media larger than the media viewer canvas to a zoom that fits inside it, the media will now re-center. See if you like this–I may make it optional. An issue with the 'the client is already running' dialog not appearing is fixed. full list - mpv: - rolled Qt back from 5.14.0 to 5.13.0 on the releases, which seems to have fixed our 'event queue sometimes halts until mouse move' issue that occurs after initial mpv load. some other ui and media viewer resize jank seems to be cleared up. I dunno what happened with 5.14, and I don't suspect it as the problem nearly as much as my currently borked Qt event processing code, but rolling back seems the easiest solution for now - fixed an issue that was crashing non-windows that were able to load mpv - mpv now loads an mpv.conf from install_dir/static/mpv-conf. please feel free to swap in another conf or edit that one as you like. I would be interested in feedback - default mpv conf is now set to specifically enable some hardware acceleration to improve playback for some users, and to never load sidecar files like subtitles as this was introducing incredibly large load lag for users with large/high latency file storage - fixed a new issue where preview windows were not unloading media (particularly significant for mpv with audio) on page change and client shutdown - fixed an issue with global volume propagation to multiple open mpv widgets - . - the rest: - added two dark qss stylesheets from the user-creation github repo to the default install - when zooming out from a zoom that makes the media bigger than the media viewer canvas to a zoom where it fits, the media will now recenter. see if you like this, maybe it should be an option - to help forestall unnamespaced filename tag spam in various new-user scenarios, the 'filename' checkbox-and-namespace widget on the filename tagging options panel now initialises with 'filename' as the namespace - fixed a recent window sizing issue with the 'the client is already running' dialog not appearing - file export paths that include subdirectories that could possibly have empty text, like "[creator]/[page]", will no longer error when this is so (e.g. if a file in this case has no creator tags)–they will eliminate the subdirectory entirely, becoming "[page]". this should work for all platforms and for any nested subdirectory - fixed an issue with some fractional dataspeeds below 1KB/s displaying with many significant figures

[Expand Post]

- improved some custom event handling definition code - reworked hydrus's internal object publisher/subscriber messaging system to be more Qt-happy - if the file import tagger is given a neighbouring .txt file to pull tags from that does not decode to utf-8 nicely, it now catches and reports the error more gracefully - reworded a bit of the installing help and first-start popup to emphasise that hydrus does not auto-update - added links to https://github.com/Zweibach/text/blob/master/Hydrus/PTR.md , a new guide for the PTR, to the help - removed the old 'hardcoded shortcuts' help entry, since it is increasingly irrelevent next week I took a bit of time off this week and rejiggered my future schedule to reduce some work stress. I feel great. Next week I would like to make some nice mpv volume controls and clear out some miscellaneous small jobs.

Anonymous 02/01/2020 (Sat) 09:19:35 Id: 238f1f No. 13582

>>13580 a bunch of my windows now default to maximum screensize, including the add/delete tag window when you select multiple files and 1+ already has the tag you're trying to add/delete. Which frame is that under gui options?

Anonymous Board Owner 02/01/2020 (Sat) 18:51:04 Id: 80c484 No. 13585

>>13582 Thank you for this report. Did you change the settings here, or has this happened out of nowhere, just after updating? The manage tags dialog when launched from thumbnail view is 'manage_tags_dialog'. Assuming it is not set to maximise or fullscreen, the default 'gravity' (of (-1, 1) ), means it is supposed to be horizontally thin but expand to be about twenty pixels shorter than the main gui (its parent). If the fix here is not obvious, could you take a screenshot of your options page here. Also, do you have a window manager that might give unusual sizes for the frame 'around' a window (the bit with close/minimise/restore buttons), whether that is a couple pixels around all edges or anything strange like a transparent effect. I recently changed that gravity calculation to take the additional frame into account, but perhaps if your window manager has weird values for that, it is having trouble.

Anonymous 02/01/2020 (Sat) 22:55:56 Id: 238f1f No. 13586

>>13585 I hadn't changed anything but it seems to have sorted itself out. I hadn't yet restarted the client after the initial update, but on re-opening it's working properly. Only thing I changed were the settings for whether content in the media viewer should be resized to fit the canvas. Specifically, setting smaller than canvas to be displayed at 100% and everything larger to be resized to canvas.

Anonymous Board Owner 02/02/2020 (Sun) 21:57:51 Id: 6c97f7 No. 13588

>>13586 Hmm, ok. Well, I am glad it fixed itself, but I have no idea what could have done it. Please let me know if it comes back or you discover anything new about this. My best guess is it is something like a virtual desktop or an unusual multi-monitor setup. I am confident the state of tags or the media zoom settings would not change the window frame size–the window doesn't typically care about contents, but it does care about monitor resolution and so on, so if your OS was temporarily reporting back something weird like 'monitor A has resolution (0, 0)', perhaps that was causing the dialog to panic and go as big as it could. Questions probably for future, if it happens again: Was the dialog simply a normal window, but maximised, or was it completely borderless fullscreen, without any frame at all? If it was a normal window, was it technically 'maximised' so the button icon in the frame up top was 'restore', or was it not maximised but was sized the same size as the screen?

Anonymous 02/03/2020 (Mon) 02:07:11 Id: 238f1f No. 13596

>>13588 It definitely didn't have a frame. At the time, a few other windows were resized too large (like manage subscriptions) and had their buttons halfway off screen.

Anonymous Board Owner 02/03/2020 (Mon) 21:10:00 Id: 58693a No. 13599

You may have noticed Endchan and the /hydrus/ bunker there is currently down. It seems like they have server trouble: https://twitter.com/EndChanXYZ/status/1223397527967289344 If/when they come back up, I'll be posting there again.

Release Tomorrow! Anonymous Board Owner 02/05/2020 (Wed) 04:16:23 Id: 2192f4 No. 13603

I had a good week, but it was a bit light again. I have nicer volume controls for mpv, and I believe I have full mpv support for the Linux build, along with a handful of bugfixes. The release should be as normal tomorrow.

Quick Reply


Sage Bypass Check