https://www.youtube.com/watch?v=BvfHlZ8QRaI windows zip: https://github.com/hydrusnetwork/hydrus/releases/download/v580/Hydrus.Network.580.-.Windows.-.Extract.only.zip exe: https://github.com/hydrusnetwork/hydrus/releases/download/v580/Hydrus.Network.580.-.Windows.-.Installer.exe macOS app: https://github.com/hydrusnetwork/hydrus/releases/download/v580/Hydrus.Network.580.-.macOS.-.App.dmg linux tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v580/Hydrus.Network.580.-.Linux.-.Executable.tar.zst I had a good week working on a mix of stuff. Full changelog: https://hydrusnetwork.github.io/hydrus/changelog.html highlights I may have fixed a program freeze when minimising to tray via the close button (the settings for this are under options->system tray). If you have had trouble with this before, please, when you are at a convenient point to risk a hang, try it again and see if you have trouble. If you do, what happens if you minimise to system tray from the file menu--still have problems, or is that reliably fine? I added a new maintenance command to tag right-click, 'regenerate tag display'. This is a catch-all job to fix bad autocomplete counts and sibling/parent display. Previously, the way to fix this was to hit a 'regen the whole cache' job under the database menu, but on large clients this could take ages--we now have a way to debug and simply, fingers crossed, just fix a bad tag, all in, typically, a few seconds. If you have any jank siblings or 'the autocomplete said (23-28), but it gave me 8 files', try it out! I fixed an issue with temp-file cleanup after importing read-only files. If you do a lot of unusual/misc hard drive imports, you might like to shut your client down, check your temp folder (hit _help->about_ to find it), and delete anything called 'hydrusXXXXXXXX'--it is all useless cruft after the client is shut down. It shouldn't come back! The new 'eye' icon in the media viewer's top hover window now has the 'apply ICC Profile stuff' option. It updates the image live, as you click it! If you are interested in ICC Profiles--and perhaps comparing this in the duplicate filter--check it out. I also added a shortcut for it, to the 'media viewer' set. The 'file log' has a new 'search for URLs' menu command, which lets you explore what has the selected URLs mapped. It is basically a copy of what I added to the media right-click 'urls' menu recently, and it'll help figure out weird URL collisions and mis-maps. The Client API '/add_tags/add_tags' command has a couple of clever new parameters to govern how deleted records are navigated. If you are doing clever migrations or other big mappings operations with the API, check it out. next week I want to get some repository janitor workflow stuff done.

>>15441 >important but subtle file import options fix: when you set a file to import to a specific destination in file import options, or you say to archive all imports, this is supposed to work even when the file is 'already in db'. this was not working when 'already in db' was caused by a 'url/hash recognised' result in the downloader system. I have fixed this; it now works for 'already in db' for url/hash/file recognised states. thank you to the user who noticed this and did the debug legwork to figure out what was going on Shit, that's exactly the opposite of what I wanted... I know it's basically a bug fix, but there are cases where I want a downloader to be universal, instead of having x downloader tabs set up for every file domain or manually deleting wrong file domains (which flags the file as deleted forever). Checkbox when?

Thanks for your hard work, hydev. I have a suggestion that you may have already heard: media viewer "profiles". You could create ones that have different default zoom levels, different shortcut sets activated, etc. And you could switch between them easily within the viewer. Also, the ability to prevent scrolling past the top/bottom of the image.

Ok, my lazy ass damn near ran out of space on my mass storage drive, so I am going though and importing a bunch of image archives to hydrus so it moves them to the image drive I have noticed that importing this way seems to stop at about 4000-5000 images processed, is there any setting that throttles how many images can be imported in one go though folder imports? also, this is more just a piece of mind thing, I like having records of what's being imported so I can see why something may have gotten disqualified. the last folder I imported had I Believe 4300 images processed, 920 came in, and the rest went straight into the recycling bin. this is an artist that I know I downloaded a lot of their crap, I know that it is probably already all in the program, but is there any way to see the file logs of folder imports? and if there isnt, is it possible to have logs added? I know this would probably take up some degree of ram/add to weight, so a way to purge this once looked though would be nice.

>>15441 >I may have fixed a program freeze when minimising to tray via the close button (the settings for this are under options->system tray). If you have had trouble with this before, please, when you are at a convenient point to risk a hang, try it again and see if you have trouble. If you do, what happens if you minimise to system tray from the file menu--still have problems, or is that reliably fine? Hi Hydev, i reported this one. Yes, it seems to have fixed it as far i can tell from the few days i have been able to test this latest version. Awesome! Originally i had only checked the "close the main window to system tray" box and it crashed when pressing the X on top right. Now it seems fixed. What was the problem and how did you find the solution :D? But i also made sure before i installed the latest version, that i try the "minimize the main window to system tray" option, in case the minimize button was also affected by the crashes, so i checked the box and even after one night and some wild minimize & maximize spam, it didn't crash. So i guess this option was always save before too. The X button (close to system tray) one i could always crash reliably before. One quick question for you: Could there be a problem using emoticons (windows key + . (dot)) or other symbols (chinese, japanes etc.) in tags in the long run? Would you say there is a chance that those could cause problems or not at all? And if not in Hydrus, maybe when copy & pasting them somewhere else, or when using sidecars? One example. One image album has a heart emoticon as title ( 🧡 <- let's see if this even shows here). would i be able to find it in the future even if microsoft changes the designs or are they somehow universal and there is little chance they won't work in the future? Weirdly enough in Hydrus the standard red heart doesnt show as red but rather white/colorless/black and is smaller. Same here: ❤ So i am not sure how reliable all those symbols are, please some suggestions how to handle this. Sorry i have no clue about this :P >>15444 >also, this is more just a piece of mind thing, I like having records of what's being imported so I can see why something may have gotten disqualified. the last folder I imported had I Believe 4300 images processed, 920 came in, and the rest went straight into the recycling bin. this is an artist that I know I downloaded a lot of their crap, I know that it is probably already all in the program, but is there any way to see the file logs of folder imports? and if there isnt, is it possible to have logs added? I know this would probably take up some degree of ram/add to weight, so a way to purge this once looked though would be nice. when manually dragging & dropping a folder into Hydrus: directly above the progression bar on the right, there is a 'file log' button with an additional arrow down button with additional options. the file log gives informations and status and with right-click on the entries, you can chose to open the selected files in a new page or more under the 'whole log' submenu in the right-click menu. Is this what you looked for? when using the automatic import and export feature: file -> import and export folders -> manage import folders... -> double click (or edit) entry you want -> under the checkboxes there is a 'file log' button which has the same options as i mentioned above. is this what you were looking for? the question about why it stopped at about 4000-5000 images, i cant answer. but you can right-click on the ones that didn't import and 'try again' for example.

>>14275 As of now, my db is over 8 years old and has over 28k files, all manually tagged by yours truly

>>15448 How the fuck do you even manage to tag stuff properly and consistently, I tried tagging things myself and ran out of steam after three images or so

>>15448 I kneel tagger-sama >t.only tags things as 'reaction image', 'meme', 'character:xyz', or 'series:abc'

>>15449 >How the fuck do you even manage to tag stuff properly and consistently, Different anon here and I tag 100% manually as >>14275 and >>15448. Currently I have 38K files with only 50% properly tagged (fully tagged and already send to archive). The answer is just to begin small and from there add little by little more tags that describe better what you have. Soon you will develop your personal system and surely find yourself deleting 100s of tags to replace them with others that suits you better. In any case you will need time and a lot of autism.

>>15419 >>15429 Thanks again for your work here, you saved me a ton of time. The 'already in db' logic and how it applies post-import content updates should all be fixed in v580 now, let me know if you still have any issues. >>15422 >>15427 >>15428 In my experience, early SSDs were terrible and I had some that just died after a year and others that lasted ten. It was often related to bad TRIM tech. I haven't had a single SSD problem in the past, I don't know, eight years or so. I think a lot of maintenance tech improved along with write reliability overall. I may just be luck though. I tend to just buy stock machines with simple non-super-gamer-mode basic NVME system drives now. That said, no matter what medium you are on, you can always have a house fire or a nephew throw orange juice all over it. A weekly backup trumps all hardware problems. >>15423 Great news, thanks for letting me know. I just got a new nvidia driver on my main vidya machine and I played an mp4 with MPC-HC right after and it caused my whole display to crash and recover, with a second of terrifying jaggy static audio. I then did it again and it happened again, and then I did it again and it was completely fine thereafter. I think GPU tech is just crazy and sometimes things are just in conflict for whatever 'it gives us +3% performance' reason, and then a patch is activated or some internal error is tripped and it switches driver flags, and it all works again. Let me know how you get on! >>15426 This is usually cloudflare. Try hopping VPN, or use Hydrus Companion to copy your User-Agent and cookies over from your browser to hydrus. >>15430 I used to be a C++ guy, funnily enough, about fifteen or twenty years ago, but I ultimately became fond of python simply because of how easy it is to write. Although there are some limititations on speed and it bloats the hell out of the install size, it allows me to rapidly prototype things and there are some great libraries that just add xyz support in a couple lines. I love not having to deal with memory or pointers, and stuff like list comprehensions are delightful. I'm not up do date on most modern coding though--I understand C# and other new languages have integrated many of the cool python features, so I can't claim I am doing anything but what is personally comfortable and what I have actually experience with. The good news is that most of the heavy grunt work in hydrus, stuff like image rendering, is actually done in the C++ level in libraries like numpy (the code kind of 'jumps down' to C++ when it hits certain dlls). This tech can also work multi-core, which current normal python can't do. When you encounter slow shit it hydrus, it is almost always due to me writing bad code, rather than it being python's fault. Usually UI code that isn't being async like it should. Let me know if you run into problems in a particular area, and you can often run help->debug->profiling to help me figure out what I did wrong.

>>15434 >>15436 Thank you for this, I will check it out and roll it into the defaults! That's neat if it works for rule34 and paheal too! Posting here is always good. I have to do a couple things to ensure the new default gets overwritten in the update, and I generally like to check what is being added since sometimes the 'hey here is a really cool downloader' that someone posts actually has some advanced stuff that isn't appropriate for all users in the defaults, so I may have to slim it down first. If you have a cool downloader that isn't appropriate for the defaults but you want to share it anyway, you can also do a pull request here, which is user-run and has a billion different downloaders: https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts >>15437 Yeah, this is intentional, but I don't know if I like it. A user mentioned that according to style guides I should show the 'undo' menu even if it has nothing to show, and I did it for the pending menu too, but I think it looks dorky. I'll probably write a checkbox to let you hide them again. >>15438 If you are back to working, that's fantastic. The shm and wal files are usually only there when you are running the db and are removed on clean exit, so you usually only have them hanging around on a crash etc... They aren't a huuuuge deal, normally. If they exist on boot, I understand that SQLite will look at them and say 'ok, looks like we have a crash last time, is there any data that was supposed to be written to the real db that I can do cleanly, or should I throw whatever is here away?' and figures it out. If your wal files got swapped around, I think that might have fucked with SQLite, yeah, but I can't be sure. I think the shm one (shared memory) is basically a place for locks for parallel acces, which doesn't matter for us, but the wal is the write-ahead log and is basically where shit about to be written to the database is stored. Let me know how you get on in future. You sound like you are focused on a good backup routine, but I'll post this anyway for you to check out: https://hydrusnetwork.github.io/hydrus/after_disaster.html >>15442 Sure, no problem. Now this code is actually properly written out instead of sort of 'accidentally running sometimes', I can wrap it in an easy yes/no and stick a checkbox on it.

>>15443 I haven't heard it exactly like this, and I think it is a great idea. I feel like I am finally getting on top of some background code cleanup around here, and now I am adding new stuff via this new 'eye' icon. Having some preset profiles you can quickly load up would be a great thing to add. First, I think, is going to be some new zoom options. Lots of users want the ability to lock zoom between files and stuff, so I'll see what I can do. Bounding pan would be neat too. I can't promise this will come quick, but I'd like to keep pushing in little waves. >>15444 >>15445 Yeah, this is very strange, an import folder shouldn't stop at 4000 files, and I know plenty of users who have used them to figure out 500,000+ file situations (import folders use far less UI resources than a normal import page, so they are useful for giganto jobs). I think, yeah, check out your 'file log' in the import folder edit panel itself, and you'll see more on what is going on. My guess is you'll have 30,000 items or something, all set 'skipped' because of some weird error. Or, if they ended up in the recycle bin, then I would think they would have hit one of the rules in the actual import folder UI, like 'if the file is already in db, delete it'. It might be worth undeleting those files and trying a normal manual page import to see better what is going on. Let me know what you see. >>15445 >What was the problem and how did you find the solution :D? This whole time I thought the problem here was with the 'hide the UI and update the system tray icon' code, but since you mentioned it was with the close button only, that explained why I wasn't able to reproduce the problem (I was always testing it through the file menu). It turns out in the tiny little event handler where I catch the close button click event, I was firing off the 'minimise to system tray' command but then was leaving the event handler without telling Qt 'I caught this event, take no futher action'. My guess is that Qt was thinking the close happened and getting into a state where it was half closed (since my real exit code also happens elsewhere), probably the main event loop was exited but the UI wasn't deleted, something like that. So, when you reactivated from the system tray (although I don't know how that would work with a dead event loop, but who knows, maybe that works immediately off the click somehow), it was frozen because no events could be processed. Anyway, as is often the case, it was one dumb line, 'event.ignore()' and it was fixed. >Could there be a problem using emoticons (windows key + . (dot)) or other symbols (chinese, japanes etc.) in tags in the long run? I don't know really. My general philosophy has been to be maximally supportive, so if it is unicode and doesn't break my basic rules (there's some stuff like a tag can't start with a hyphen or 'system:'), I clip it to 1024 characters for safety and just save it. We've got a load of weird kanji, hangul, chinese, and emoticons, and these new combined emoticons (like if you combine girl + elf, in some render engines it'll render 'elf girl' instead of two characters, or now I think of it I think that's how the coloured heart works), mostly through parsing some weird bit of title html here and there. Now that we are in python 3, where unicode is a delight to work with, and now that basically every OS and other piece of software will eat UTF-8 no problem, there basically aren't any technical problems with this. If you paste ZALGO or other bullshit into the client, it'll eat that and render it all fucked up, but it works. 99% of the time, I just see it as a string. Will unicode change in future, and will these custom emojis change? I don't think they'll change much, since most of this is baked into the official unicode standard now. These custom renders might change. But I imagine the way it will go is we'll have ten new ways to say 'pregnant male' so as to include x racial group or y sexual orientation or z allergy sufferer. Overall, I think I don't recommend these characters, but I'll save and throw them at the render engine, so feel free if you like them. If Qt and/or your OS decides to draw them different in ten years, that's a risk, but I don't think it'll be a technical problem ever. If there ever is a unicode 'schism' where we decide it is all too much, I imagine there will be (if there isn't already), a nice way to filter out bullshit characters and just stick to normal human letters and logograms. I also don't like them since typing them (and thus searching with them) is a pain. Tags are for searching, not describing!

>>15448 >>15451

>>15452 >A weekly backup trumps all hardware problems.

I've imported some files from a variety of downloaders and would like to set their modified time to their earliest web domain date, so that they're essentially sorted in order of first publication. Is this currently possible? (I'm willing to write basic scripting)

>>15453 >Sure, no problem. Now this code is actually properly written out instead of sort of 'accidentally running sometimes', I can wrap it in an easy yes/no and stick a checkbox on it. Sounds good! I'll wait for the next version before updating then.

I don't know how to interpret this at all.

>>15461 Post Hydrus version. Better yet, the information found at Help>About.

>>15448 Your DB and file accumulation rate are about the same as mine. I had about 24k files after 8 years. I have now spent the past couple years tagging and have tagged 28k files. I added roughly 11k in those past couple years though because Hydrus makes it easier to collect. I track my file processing and downloading, and I'm keeping ahead of my download pace. Might catch up within the next year. Gonna suddenly have a lot of spare time then.

>>15451 >Siblings In my perfect hand made garden, there are only ideal tags. With maybe a couple exceptions for things I keep misspelling like Yokai/Youkai Watch. I tag files in batches of about 200-400 at a time before archiving them. Where was it that I could view my total tags and tag relationships again?

regarding sankaku, is there an alternative downloader since hydrus is unfeasible for this?

I found a problem with the "neighbor spam" check. It seems like it's incorrectly denying file url checks as being correct, even when each file url is only mapped to one file. The post url does contain multiple files, but in the url class, it says it does, so I expect hydrus to still check file urls and avoid redownloading if it sees that url on a file. But it doesn't. it downloads the file every time and ignores the file url being present already. Turning off the neighbor spam check fixes this issue, which is weird since the neighbor spam checkbox only mentions checking post urls, not file urls.

>>15469 this is just a guess, but since this is the first time I'm seeing this issue, and I'm on v579, maybe it the issue has something to do with this change you made in v579: >I've improved some 'hey I think we already saw this URL before' logic, fixing an awkward false positive result. If you have had incorrect 'already in db' on slightly different versions of a file on a booru, and you traced it to a bad source url, they should work in future.

>>15469 >>15470 I should probably also mention that I'm having the issue specifically with the kemono.su downloader which uses an api, then associates the original post url, if that makes a difference.

>>15454 >So, when you reactivated from the system tray (although I don't know how that would work with a dead event loop, but who knows, maybe that works immediately off the click somehow), it was frozen because no events could be processed. Anyway, as is often the case, it was one dumb line, 'event.ignore()' and it was fixed. I always find it strange that bugs like this one don't happen every single time. With this bug, it only happend more likely (or very likely) after it was minimized for some time or after minimizing and then maximizing several times in a row, then out of nowhere it randomly crashed. In the future when AI helps you tracking them down, i hope you will be able to spend less time fixing those annoying bugs. _ Regarding emoticons: i've tested alot of the smiley and heart ones mostly. can you explain why very few show somewhat wrong in hydrus and also here. For example those show colorless/black/less detailed -> ❤ (default red heart) , ❣ (red heart as exclamation mark). they both show correctly here though when you type it direclty after another symbol without whitespace like this 💔❣ ,🧡❤ but not in hydrus. also not in latest chrome, but here this workaround is possible because of my old firefox version im using right now, so it won't work for you i guess. other emoticons (which are also working without whitespace) are the smiling face ☺ next to 😚🙂 and a very sad face ☹ next to 😲🙁 some ultra weird behavior: when i type the smiling face first and the very sad face directly after that without whitespace, all others after that also stop showing the detailed version until i hit one that stop this behavior (only old firefox) -> ☺☹🙁😒🤤😜😯😫🥱😣🙂😚😪🥱😌😟🎪 Ok i get it, different programs show them differently and per version, and the behavior in hydrus seems to be dependend on Qt as you said. But why is it that nowhere it is possible to render the 2 smileys (smiling face + very sad) and 2 hearts (default red + exclamation mark) just as Windows shows it when pressing win+(dot)? It is really not that serious, but im just interested and you can explain it nicely :) _ It seems hydrus doesn't support .url files. Wouldn't it be very easy for you to support them? Like clicking on one and then show the 'open externally' button which calls your default browser. And since all of them have obviously a URL: , you could fetch/parse the url easily so it could show with right-click -> urls, so they could be searched for easily with system:urls too. I got alot of .url files saved throughout the years because it's not always worth saving huge files locally. Also tagging isnt that good or doesnt work at all in browsers. Also privacy. Thanks and have a nice week!

>>15474 >💔❣ ,🧡❤ ok in chrome the second of each shows wrong as expected, only in my old firefox (maybe new too idk) they show correctly with that workaround. >>15474 >☺☹🙁😒🤤😜😯😫🥱😣🙂😚😪🥱😌😟🎪 here also the first two show wrong in chrome. the weird behaviour only shows in firefox where it shows the first eight emoticons wrong. Anyway, my question in the last paragraph stands. Why aren't the 4 emoticons -> 2 smileys (smiling face + very sad) and 2 hearts (default red + exclamation mark), not rendering correctly anywhere?

What does this metadata even describe? Is it worth keeping it around?

>>15480 Dots per inch. Google it. "If an image has a resolution of 300 DPI, this means that every inch contains 300 dots of ink. Photographers and graphic designers typically use 300 DPI as a benchmark for printing high-quality images." It determines the quality of a print. The higher the denser. If you print something you don't print pixels, but dots. With lower dpi an image is printed bigger on a sheet of paper when printing in 'original size'. For example: image with 1000x1000 pixel resolution and DPI (dots per INCH) with 1000x1000 will print with the size of 1 x 1 inch (or 2.54 x 2.54 cm) on the sheet. If you halve the DPI to 500x500, it will print with the size of 2 x 2 inch (or 5.1 x 5.1 cm). Of course printer settings allow you to stretch/resize and whatnot anyway. Same goes with scanning. The higher the DPI settings in your scanner, the bigger the filesize and resolution, because the sheet size is already a given with the A4 format normally. Also when creating PDFs out of images, the image sizes can differ hugely if they don't have a similar DPI, even though they have the same resolution. Because the PDF viewer (for example in whatsapp) determines the display size of the images according to the DPI/resolution ratio. Is it worth keeping around? It is embedded metadata, imported with the images. So how can you not keep it around?! You would have to export images which have a set DPI, then find a tool that can strip/delete it, save the image and then import it again, which wouldn't be recognized since the hash changes i guess. So i guess nope.

>>15481 Well yes I know what dpi is generally, but does it do anything for pictures in Hydrus is what I meant. I have a lot of pixel duplicates where the only difference is a dpi entry and ~0.1 kb size difference and I'm wondering if it'd be better to keep the picture with the dpi metadata vs the one stripped of it.

Tell me why converting all my pngs to lossless webp is a bad idea. Also, do you keep jpg or png when you can't tell the difference between the two? But, like, you're not sure if they're nigh identical since they're not pixel dupes.

>>15484 >But, like, you're not sure if they're nigh identical since they're not pixel dupes. If they're nigh identical and same dimensions, I keep the smaller filesize.

>>15484 If you use the PTR then converting them to a new format means they would not be tagged in the PTR. So I would say do not do that if you use the PTR and care about things being tagged. If you don't use the PTR (and don't plan to) then there's no real harm in it. As to similar files, in that situation I choose whichever one has more PTR tags. That file is more likely to get updated in the PTR. If there's no PTR tags I would keep the one in the better format. If the same format, then the smaller one.

When permanently deleting an image it is put into an in-between state until the client is restarted - The trash icon is absent and the image remains in the cache until pushed out. You can see this when using the "all known files with tags" view where confirming a permanent deletion will remove the image from view but refreshing the page will bring it back.

>>15484 >Tell me why converting all my pngs to lossless webp is a bad idea. because the disk space savings are so tiny it's literally not worth your time. you'd have to export all the images, convert them, and then reimport and have to go through the duplicate filter or whatever to copy all your shit over to the new one.

>>15482 Depends on your level of autism. If you like it clean, take the one without dpi metadata. If you ever plan to print something, or do something with that file outside of hydrus, that relies on dpi, then you can keep the one with dpi. It's not like an image needs that value and it can be changed/set with programs like irfanview in case you ever need it. Since you cant search for dpi values with a search predicate within hydrus, it doesnt matter. Maybe it will support dpi search in the future? In your second pic, it says 73 tags > 7 tags. Wouldn't it be better to take the 73 tags one? I know you can merge them, but regarding PTR, isn't it like the ones which have more tags, will get updated more likely in the future too? Because that is a file/hash more people have and so the chances are higher? Just like >>15486 said. I'd take the 73 tags one therefore. >>15487 Correct me if im wrong, but as far i remember testing, restarting does trigger some maintenance jobs immediately and therefore you see that behavior. If you let the client idle for some time, maybe not using the computer at all (while it is still on obviously), those jobs start also and you will eventually see them deleted just like after restarting. It's on purpose because hydrus doesn't want to take resources away while you might need them or to stay snappy. Probably you can even force some maintenance jobs like this without restarting. Hydev might answer this. >You can see this when using the "all known files with tags" view where confirming a permanent deletion will remove the image from view but refreshing the page will bring it back. Keep in mind that even when deleting a file permanently and not leaving a deletion record, the file will still be in the 'all know files with tags' location, when the files had tags. Even after restart. The thumbnail might get blurry (-> space saving blurhash) after restart directly, but that will happen also after you leave the client idle for some time as i said before, at least im really sure about that. The permanent deletion doesn't wipe the records completely, even when not leaving a deletion record. For reference: https://hydrusnetwork.github.io/hydrus/faq.html#does_the_metadata_for_files_i_deleted_mean_there_is_some_kind_of_a_permanent_record_of_which_files_my_client_has_heard_about_andor_seen_directly_even_if_i_purge_the_deletion_record "Yes. I am working on updating the database infrastructure to allow a full purge, but the structure is complicated, so it will take some time. If you are afraid of someone stealing your hard drive and matriculating your sordid MLP collection (or, in this case, the historical log of horrors that you rejected), do some research into drive encryption. Hydrus runs fine off an encrypted disk." It doesn't say if it does finally when you delete the tags or if remnants like a hash will always stay in the database no matter what, even after deleting the tags. Hydev?

I had a great week working on some new janitor tech that makes it easy to thoroughly delete tags from a repository. I also cleaned a bunch of code and, for normal users, improved some quality of life. The release should be as normal tomorrow. >>15461 Please hit the 'Linux' tab here https://hydrusnetwork.github.io/hydrus/getting_started_installing.html#installing and ctrl+f for that 'g_module' string. There are a couple of ways to fix this, I understand, but I am no Linux expert so I cannot talk too cleverly.