>>20315 nevermind I'm retarded lol

Updated from 534 to 544. Now Hydrus displays dropdowns in the wrong location when I have two displays and all my thumbs are too small. If I swap my primary display, both of these things go back to normal, but every time I minimize and maximize Hydrus, it shows up on the bottom display instead of the top.

>>20317 It also opens the image viewer on the wrong display. If I have main display swapped so that everything appears as it normally did before updating, it refuses to open the tag management window in the bottom display like it used to, so I can't tag while viewing an image without setting tag managament dialogue and frame to start unmaximised, and unfullscreen, and then dragging it down. Setting it remember position and size just resets to the top display every time no matter where I last closed it.

>>20318 >>20317 Additionally, leaving my main display as is cause the imageviewer to always show up on the bottom display, and the maximize and minimize issue is apparently the same regardless of which main display I use.

>>20317 >>20318 >>20319 Unplugging and re-plugging the HDMI cord has somehow fixed the minimize maximize issue. Keeping my main display swapped fixes everything but two issues. I still can't get tag management dialogue+frame to stop resetting to the top display, and every time I use the media viewer, though it visibly functions properly, it always throws a "rescued from apparent off-screen" error.

>>20320 unfullscreen and unmaximize media viewer and then close it and reopen it

>>20321 This stops it from throwing an error when I have my displays swapped, but the main issue of my tag management dialogue/frame being forced to the secondary display remains. When I swap my primary display back to top screen and the tag managers go to the bottom like I want, dropdown menus and windows of all kinds are always forced to the bottom secondary screen regardless of where I last left them with "remember position" set to true. The minimizing/maximizing issue comes back when I swap displays and isn't acutally remedied by removing and replugging in the HDMI cord. In actuality, removing and replugging in the HDMI cord allows me to sometimes change which display the main Hydrus window "sticks" to when I minimize and then maximize it.

>>20322 Also, half the time the windows forced to the secondary display will throw a "rescued" error. It's quite frustrating. Over the last few months, I've grown very accustomed to having two screens for Hydrus. Being able to view an image in full detail via the media viewer while I type the tags in is a godsend. It's just F3, tag, F3, right arrow key, repeat whenever I'm not tagging groups of files at a time.

Bug report with the note display with an open image, see webm, spoilered for some lewd thumbnails. The stutter was just Hydrus freezing for a second, ignore that part, I run Hydrus with a lot of weight. System info: Linux, Running from source, Qt version 6.5.2, see picture for the rest of the details.

>>20324 Hold on, that webm is absurd, use this one.

>>20317 >>20322 I found a strange behavior I can exploit that gets me 95% back to normal. With the bottom screen set as primary display, the only remaining issue was the tag management windows being forced to the secondary upper display even with remember position on. If I have the tag management window on both screens, it will stay where I left it if more than half of it is still on the top/secondary screen. However, if I then slowly move it down while closing and reopening it to change its saved position, I can edge the window down until nothing but title bar is on the top/secondary screen without it losing its remembered position. With this I can tag full size images/videos again with only a tiny fraction of them covered by the tag manager, and nothing important in thumbnails will be covered either when tagging multiple files at once. The only moderate drawback is that Hydrus considers the tag management window to be in the top/secondary screen, and this forces all dropdown menus opened within it open in the top/secondary screen, so modifying parents on the fly is slower.

>>20324 This got a chuckle out of me. You got any more of these with girls doing poses from Baki?

>>20322 >the main Hydrus window "sticks" to when I minimize and then maximize it. i'll say it again. unmaximize the main hydrus window, and then move it your other screen and maximize it again. this advice didn't only apply to the media viewer. if you move a window directly from maximized on one display to maximized on the other, it doesn't change its actual x/y position.

I'm not aware of any, but here's some more memes by centurii. Most of this is horrendously tagged cause it's pulled in from twitter or kemonoparty.

I have many imported files that have stuff like "part 1" or "part 2" in the title. Is it possible to parse the title tags within hydrus or should I export my files again

>>20330 With parsing I mean creating page tags, whenever the parser encounters "part <any number>"

Also is there a way to search for titles that contain brackets? looking for title:*[* doesn't seem to work

>>20324 >mpv api version:2.1 >weird window behavior From the mpv version I would assume you are running on Manjaro with KDE. I had some intermittent issues that might be related, including the mouse pointer losing focus inside the area of the Hydrus viewer. I'm not sure if it is related, but If KDE is what you are running, the fix might be to disable some Plasma effects. See pic.

>>20317 I want to have your nanachis :§ >>20316 me too >>20304 hey, I recently solved compatibility issues by installing from source (thanks mr. dev-kun) i got it via "git clone" when i try "git pull" it tells me: git pull Updating 36830964..428372fb error: Your local changes to the following files would be overwritten by merge: setup_venv.sh Please commit your changes or stash them before you merge. Aborting Disclaimer: I dont know how to use git and dont fully understand it.

>>20334 >how update source install NVM, I think I managed to do it Just created some sort of backup branch and then I could do the pull Even ran the venv script as per >>20304 and am now hopefully not gonna get raped by the webp vuln thanks folks >>20317 I still want those nanachis though (pls) :§

>>20328 Ah yes, I'm just retarded and thought I tried that already. Clears that right up. >>20334 >>20335 >>>/b/450661 It's a start.

>>20335 >Just created some sort of backup branch and then I could do the pull I have no understanding of git either and I do a manual update from source without issues. 1 - Download source code and decompress it. See pic 1 2 - The content of that decompressed file, you are going to drop it inside the folder where Hydrus was already running and overwrite the files inside. Obviously this method is for fags already running from source; regular installations need to overwrite files with the regular proper installer or executable ("file.Executable.tar.gz" or "file.Extract.only.zip"). See pic 2. 3 - Done. By the way, it is not necessary to run the venv again after this drop and overwrite update, unless devanon says so. Caveat: If the database folder is located outside the Hydrus folder, for example in another Drive, you will need to type the PATH of that db folder in the "hydrus_client.sh" file, as it was overwritten by the update. See pic 3.

>>20317 >>20335 I see fellow Nanachi lovers. You should also check out the following boorus: https://bune.booru.org/ (SFW and NSFW) https://naa.booru.org/ (SFW only) I've been going thru and tagging these for the PTR, plus a ton more from Pixiv, but it's a never ending process.

>>20329 Meant for >>20327

>>20324 >>20333 Thanks for the reply, I'm actually running Gentoo with AwesomeWM. Although mouse pointer focus things might still be the cause, I use focus follows mouse so whatever I hover gets brought to the forefront, I find it far more comfortable than clicking on a window to use that program, but some applications don't handle it too well. The temporary freeze of Hydrus isn't what I was trying to convey, I was just fed up cause I'd already re-recorded the video a few times. Here's a better webm, showing the only thing I suggest to be a bug.

>>20334 I use git for quite a few things, so I have *some* experience with it, but I'm not a dev so I don't know every facet of git. First of all, if all you've done is changed the setup_venv.sh to executable with chmod +x you can safely "git restore" (git restore setup_venv.sh) it, but you'll have to re-chmod it next time you want to run it. Second, if you do need to save the changes, you could do a "git stash save" or "git stash push" to "reset" your file to the remote one (the one in the repository) while saving a copy, and then you can "git stash pop" to return your modified one (if necessary). You can also make a commit and rebase on top of it but that's a little more complex then I think I can explain. >>20335 That works too, to keep your local branch up-to-date you'll want to: >git checkout master >git pull >git checkout (your local branch) >git merge master It's kind of a hassle, you may want to make a script that does that for you. Hope these tips help. Once you get the hang of it git becomes very convenient, for instance I have a git repo for none other than ... git repos. I can update all of them at once with a single command and keep a backup on my server so I can easily re-access software I want to have a copy of.

>>20338 I'm too picky to ever have thousands of Nanachis. I only have a couple hundred, but in a couple months I may go on a crawl and double that. >https://bune.booru.org/ (SFW and NSFW) This operates as part of The Booru Project, which bans loli among other contentious fetishes. This is at risk of being nuked at any moment if anyone ever catches wind of it, given it's a NSFW booru centered around a loli. Good on ya for backing these up.

I had a good week. There's support for epub files, some new micro-thumbnail tech called a blurhash, and the file history chart now has a file search box. The release should be as normal tomorrow.

>>20336 thanks and cool :3 nyaa >>20337 >1 DL code&decompress (pic 1) I did it via git clone though? >2 Copy into Hydrus dir and overwrite pre-existing files I did a clean install and simply copied my db folder into the git cloned directory? It's working and updated to the newest version after I managed to do the git pull <the primary problem for me was git not allowing me to do the pull and it seems without consequence to just make a temporary branch, then do the pull and then delete the temp branch <I guess that's some kind of safety feature? >(for fruitfrens already running source; reg. installs overwrite using the installer/executable) (pic 2) >3 fin >not necessary to run the venv again after update thanks for clueing me in on that so I guess all that is really required is that "git pull" devanon mentioned, right? >unless devanon says so yeah, did it due to the webp oopsie remote access submissive and breedable seems I am using the patched verion of Pillow lib now though >Caveat: >If the database folder is located outside the Hydrus folder, for example in another Drive, you will >need to type the PATH of that db folder in the "hydrus_client.sh" file, >as it was overwritten by the update. See pic 3. For now all is on one drive, my collection is nowhere near as huge as you guys seem to have Thanks for the spoonfeeding and sorry for asking dumb questions >>20338 b-b-based and redpilled ?! >>20341 >redo chmod +x yup, I think that "unsaved change" is what prevented me from pulling in the first place >stash save/push/reset okay, I might just try to DL an old version and play around with these commands to understand what they do in another new directory >stash pop so that's incase I want to "roll back" an update? >commit/rebase or is this one in case I want to "roll back" an update? >git checkout master + git pull + git checkout backupbranch + git merge master Oh, so that's the "proper" way to do it? In this case all I'm "merging" on my end is the chmod +x I set on those 1 or 2 files, right? Anywas, you don't need to answer my questions, I think I managed to gain some understanding already from your reply - thank you for that. >>20343 Glad you had a good week and thanks for the awesome work. What you do is unfathomable to me…

>>20338 How do I download from a normal "booru" project site in hydrusnetwork? all my stuff has been manual until now and I barely managed to find my way into the user interface with that

Going to make a new thread for the release today, so clearing my replies now. >>20310 I broadly agree with this, although due to hydrus philosophy, I'll want to be careful about it. It is important to us that file hashes (i.e. file content) does not change, so while I could hack in some hardcoded 'on export, scale to x bounding box and save to jpeg' commands, I think I'll ultimately design a whole 'conversion module' that will do all file conversion, including that internal within the client, that will also be integrated into the (hopefully more automatic by then) duplicate system. I wouldn't be surprised if this comes with/after I figure out my 'executable manager' plan, which will 'register' imagemagick and ffmpeg and any other executable as a thing that can take a file of type x and with parameters y produce an output of type z. Ultimately I hope to make a bunch of lego blocks here that you could stick into the export pipeline to say 'oh yeah, turn all these giganto pngs into reasonable jpegs using this saved conversion profile I have set up'. I foresee a time when we convert all our old sRGB images to jpegxl or some other new format, likely with AI to fill out the colourspace and do some upscaling, so, assuming that conversion would be an exe or API call, this would also plug into that. Obviously this will be a significant amount of work, so for now I recommend you hack something together with a batch script and imagemagick on your actual export folder. Hydrus is simply not ready to convert files yet. >>20312 Yeah, I don't like how slow it can be sometimes. If it helps, you can set up 'hit "f" to add "favourite"' tag commands in the file->shortcuts system, under the 'media actions' set. Also, under options->tag suggestions, you can turn on some additional columns for the manage tags dialog. The 'related' column can be pretty neat. Also, my two rules for tagging-and-not-going-crazy are: 1. Don't try to be perfect. 2. Only add the tags that you would actually search. Broadly, tags are for searching, not describing. 'fishnets' is a great tag if you ever search for that. 'brown shirt' is almost certainly useless, since one never searches for that and it doesn't help to describe since you can see it with your own eyes once the image is loaded.

>>20317 Hey, I am sorry for the trouble here. I have had a couple of reports like this now. I do not know precisely what causes it--I thought it was a Win 10 only issue, but then a Win 11 user reported it. I presume it is an essentially random Qt-display driver bug. It happens in the newer Qt version we went up to a few weeks ago. Unfortunately, I had to update to that 6.5.2 to fix severe bugs other users had, but then that leaves you in the lurch. You have two options: 1. Roll back to v537 (i.e. roll back to your v534 backup and then update to v537), which is the last version that didn't have this bug, and wait for the next Qt update we roll out to see if it fixes it. 2. Become a 'running from source' user. Here is the full help: https://hydrusnetwork.github.io/hydrus/running_from_source.html I have added a special choice to the 'running from source' setup script for people with this bug. You will want to choose the 'm' for 'Qt6 (m)iddle' choice when the 'advanced' side of the setup script asks you which Qt version you want. It should fix you up completely, and you can similarly try out new Qt versions when they come out to see if the bug is fixed simply by 'rebuilding your venv'. I have tried to make this as easy as possible these days, basically just extracting a zip and then double-clicking a couple of batch files, but let me know if I can help with anything specific. >>20324 >>20325 >>20340 Damn, thank you for this report. It looks like the note hover isn't figuring out the right size on the initial show, but afterwards it is recalcing correctly. I will check this out. >>20330 >>20331 Not yet within hydrus. Eventually I plan to make an 'internal metadata conversion' system using parts of the sidecar code that'll essentially pull from an existing internal metadata source (e.g. your tags), do string conversions to it, and then export to an internal metadata destination (e.g. your tags again), but for now I think you would have to do this manually. If you have a lot to do and can do scripting, the Client API may be your best shot. Otherwise you would probably be looking at some sidecar hacks--exporting the files with sidecars, altering the sidecars, and then re-importing (although I'm not sure how you'd best delete the old bad tags).

>>20345 Let me just preface this wall of text with saying that there is almost certainly a better, less janky way to do the later parts of this. But it works for me so that's good enough. Hydrus Companion is your friend! https://gitgud.io/prkc/hydrus-companion It's a browser extension that allows you send things directly to Hydrus. You can send a tab or tabs to be imported directly, send cookies to Hydrus, watch threads to auto grab attachments, and quite a bit more. It does require a little bit of setup with the Hydrus API, but I managed it and I'm an idiot, so I'm sure you can manage. The setup walk-thru is very clear and straightforward. For booru.org just open the images you want in a tab, then send the tabs you want to Hydrus with Hydrus Companion. Then by magic they will appear in an import tab in Hydrus (it'll create one if you don't have an existing one). And that's it! You could do the same thing by hand by copy and pasting the url for each post into a url import, but that will get really tedious fast if you're doing a lot. If you just want to add a few things, this simplifies things greatly and is likely all you need. Most likely you can stop reading this post here. You probably don't need to know any of the following, but it's what I did to automate grabbing all of both boorus. It's janky AF, but it works. If you want to go nuclear and shotgun the whole thing you can often just send each galley page to hydrus (via url import or Hydrus Companion). This works on most boorus, but I never got it to work with booru.org for some reason. And no way in hell am I gonna manually open hundreds of tabs to import each post individually. Link Gopher to the rescue! https://sites.google.com/site/linkgopher/ Link Gopher is a browser extension that will grab all links on a page or all links matching your filter. If you grab all links on a booru.org page you'll see real fast that the url for every post is the same except for the ID number at the end of the url. Crucially, those urls only have the term "view&id=" in them. So you can filter all links by the term "view" and get a list of all the post urls on a gallery page. Copy and paste the whole list to the hydrus url downloader to grab the whole page! There's only 11 pages so it's not so bad. Obviously, different sites have different urls schemes, but the process is the same once you find something unique to the post urls to filter by. I use this method mainly for my Pixiv bookmarks page. Most of that gets bookmarked on mobile so I use Link Gopher to send everything to Hydrus once I'm at the desktop. Much easier than opening a few dozen tabs once you get the process down. You can go a bit farther into the jank and grab the entire booru at once! With a bit of excel magic you can create a list of all the urls to paste into Hydrus pretty easily. The oldest post ID is 1. Newest (atm) is 1408. Use Excel (LibreOffice works too) and make a list of 1 to 1408 in column B. Then copy all of the url of a EXCEPT the ID number at the end. Paste this truncated url in cell A1. Use autofill column A to duplicate that truncated url 1407 times. You should have an easy list of all post urls in two columns. Copy and paste everything into Notepad. This will leave a tab between the url and the ID number. A simple find and replace to change the tab with nothing gives the final url list of all 1408 posts on bune.booru. Copy and paste all that into hydrus and let it run. Hopefully that all made something resembling sense. As I said... janky. There's a better way I'm sure but maybe I'll have time to look into something less manual when I get thru my current batch of 16,000 images to tag! It's not particularly difficult, but definitely more unconventional and hands-on than I would prefer. But it works and that's the main thing. It may make some more sense if you see the url list to see the ID numbers increment. So here's a list of every post url on both Naa and Bune boorus at https://pastebin.com/raw/H7PPvfnC You can copy and paste that whole list if you want to be lazy. It sounds involved when all written out, but it took under a minute to make that. I wouldn't normally recommend grabbing entire boorus, but both are quite small and inactive (87 and 1408 posts).

>>20332 Not yet. Weird characters like ()[]{}_ are collapsed into whitespace in the tag search system (so if you type 'screaming internally', '[screaming internally]' will show up as a result, and vice versa), but I plan to write a special system predicate that does an expensive 'raw' tag search on exact characters and some other variables. >>20337 The neat thing about git and 'git pull' is you update in about 3 seconds, with no worries about what you are overwriting when you extract to update. I would recommend it harder as the canonical way to do it, but for Windows users the only good option I know of that gives you 'git' on the command line is 'Git for Windows', and it has a fucking nightmare install wizard. Something like 11 choice windows, all on technical 'do you want to use the native PuTTY or your own', which normal users, and especially Windows users, don't care about. I may write a 'how to install git on Windows' guide with the sensible install choices, but perhaps there is a chocolatey solution or something that makes it one line and you are rock and roll ready to go. One thing about editing hydrus_client.sh: you might like to duplicate it to and edit 'hydrus_client-user.sh' instead. That won't be overwritten when you re-extract to update, and I have a special rule in the '.gitignore' file that means git won't ever overwrite it either, or consider it a change, if you ever do migrate to using git. >>20341 As a side thing, I'll confess that I'm shit at using git. I'm slowly learning it now I'm interfacing with it more these days, but I've been a solo dev almost my whole time programming and I hate working out branch conflicts and so on. When I was learning, SVN was the bleeding edge and I only ever used it for backup purposes. Never learned properly about forking and all that until a couple years ago. My emergency button when I really fuck up the local store is usually just to delete the whole thing and checkout again. >>20345 >>20348 Based longpost. I won't add much, but if you want internal hydrus support for a site that doesn't come by default, including many of the booru.org ones, the following is a general good pattern, but bear in mind that this can get advanced, so don't worry if you would rather get more comfortable with the program first. Also, my downloader engine is really shit to update at times, and often the updating-a-broken-downloader solution is 'delete all the objects you imported before and then reimport the new ones', or you can end up with a mess of 'downloader objects' that gets in a bit of a tangle: - Go here, https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts/tree/master/Downloaders , search for the site you want. - Download the raw 'png' file. - Drag and drop the png onto Lain under network->downloaders->import downloaders. And you should be good, the new downloader will appear in your gallery downloader pages and subscriptions. Bear in mind that downloaders can break when a site updates, and we don't monitor/test them regularly outside of user reports, so none of those on that repository are absolutely guaranteed to work. The 'booru.org' directory has more instructions and more than a thousand 'GUGs'. If you want that nanachi booru, I'm not sure it'll be listed, but if you play around with the system, you might see how it works and be able to duplicate and edit a GUG to work (under network->downloader components->gallery url generators, and then maybe a manual hookup under manage url class links under the same menu).

New thread here >>>/t/13212 I'll post v545 to it later today, and this thread should be migrated to /hydrus/ soon. Thanks everyone!

>>20344 >I guess that's some kind of safety feature? Since git is a version control software it intentionally makes it hard to lose "progress" if you stage and commit often, so that's why it doesn't let you overwrite changes easily. It would be poor design to easily/silently let you clobber files. >commit/rebase In git, a "commit" is basically a snapshot of the files at a certain moment in time with a message "yes, these changes are real" but you don't actually need to commit, you can delete the commit before pushing, but even if you delete only the files and not the commit, if they've been commited they're still safe. Pushing a commit to the remote (server) tells everyone else that the changes are real, you can easily remove a commit before you push it but if you try to remove it afterward pushing it it's a big hassle, since it's playing with "time". A 'rebase' is what you'd do if you had diverging branches, say for instance you're working with someone else, you both pull from the latest commit, but you commit & push your work before the other person, since git is a sort of 'timeline' all commits come from every commit before, but you both started from the same point in time and now the 'timeline' is wonky, you'd have to rebase your changes onto the new branch. A rebase is a way to "easily" do that, but many find it confusing, I don't have a very good grasp of it either. You probably won't need to rebase if you're just pulling updates from a software repo, but if you're doing development work to submit changes upstream it may be necessary. >stash 'git stash push' adds all uncommited changes to a sort of side place, the stash, useful if you have important work but it's not done/you don't want to commit it yet. 'git stash pop' returns the files from a stash, and deletes the stash (just the one you popped) undoing a 'git stash push'. Think of the stash as a "fake commit" that is technically temporary. You can also easily delete it with a 'git stash drop stash@\{#}' where # is the stash number you want to delete without saving >roll back As for rolling back an update, say for instance hydrus v534 was bad, you found out before you started the database and upgraded to v534, to "roll back" to 533 you would need to use "git checkout", it can be used for branches as well as commits, so to checkout branch "test" you'd use 'git checkout test'. To checkout a specific commit there's a couple things you can do, you could use the reference, an exclusive sha-1 hash of a certain commit, Hydrus v533's first release has reference '8b3ae4ac1a006e955addefb7a8af47a4e2b6336c' so you'd 'git checkout 8b3ae4ac1a006e955addefb7a8af47a4e2b6336c '. You can also use the shortref, a truncated version of the hash for that commit, which would look like 'git checkout 8b3ae4ac'. If the commit is more recent, say it was the second to last you could go off of the HEAD position (the most recent), so you could 'git checkout HEAD^^' for 2 commits up. You can also use 'HEAD~#', where # is the number of commits up, so you wanted to go 11 commits back instead of typing 11 carets you'd just 'git checkout HEAD~11' You can /also/ use the tag, if a developer uses them, hydrus thankfully does so all you'd need to do is a 'git checkout v533' which is actually a different commit since v533's initial release had a hotfix for a type check. >In this case all I'm "merging" on my end is the chmod +x I set on those 1 or 2 files, right? If there's no other files listed when you try to pull the latest update, yes. You can run 'git status' to see what files have changed. This kind of turned into a git seminar holy hell, I'll wrap this up. If you want to read more about git you can check out the pro git book, it was helpful when I was trying to set up a git repo on my server. https://git-scm.com/book/en/v2 The man pages for git are also pretty good, the main issue for a lot of people (me included) is that git uses kind of bizarre terminology, e.g. commits, pull requests, stash push/pop, rebase, fetch is different from pull, etc. Running just 'git' in your terminal emulator will give you a good rundown of the broad strokes, and since git is the most popular vcs you should be able to find a solution to literally every issue you encounter.