>>18226 Very sorry for your loss. Family comes first in difficult times like these. Take all the time you need.

>>18226 Oh shit that's terrible! Well just keep us up to date whenever you can but yeah family first man

>>18226 Sorry to hear. F to pay respects. Take whatever time you need. We're not going anywhere.

>>18226 F

>>18226 ah shit sorry for your loss

>>18226 good thing i read this before bumping my issue sorry to hear that, fren

Under windows 10 499QT6 seems to have introduced instabilities, which are fixed upon moving the database back to 498QT6 Images downloaded in 499 say No media to display, before crashing, though images are present on disk and thumbs are correct. It displays images downloaded in previous versions, but crashes almost instantly. File integrity/presents check report no problems. All file prompts crash it (import file/folder, migrate db directory selection) even when use Qt file/directory selection dialogs is enabled. Nothing is logged for these crashes

>>18234 Maybe triggered by continuing a gallery download started in 498, as the No media to display isn't shown for images downloaded in 499 from a new downloader, still crashes shortly after opening them though

>>18225 logs are in the db folder. "client - [year]-[month].log"

>>17886 >I'd estimate it takes a couple months of background work to fully catch up Woah fuck this

>>18226 F

>>18181 In regard to the "Running from source" docs, venv/bin/activate seems to be a no-go. I don't know if it's out of date or version specific or what, but for my python 3.9.6 install, it's venv/Scripts/activate And sorry to hear about you dad, dev.

>>18239 Hi, I'm an idiot. Disregard my fuckery. Except for the last line. My condolences.

>>18237 Yeah unless your file collection is both huge and constantly growing, the ptr isn't really worth it imo. I used to sync with it but I stopped around last year.

>>18226 F

>>18213 here. I'm trying to run from source, but can't get it to work. Traceback (most recent call last): File "C:\x\Hydrus Network\hydrus\hydrus_client.py", line 19, in <module> from hydrus.core import HydrusBoot File "C:\x\Hydrus Network\hydrus\core\HydrusBoot.py", line 3, in <module> from hydrus.core import HydrusConstants as HC File "C:\x\Hydrus Network\hydrus\core\HydrusConstants.py", line 5, in <module> import yaml ModuleNotFoundError: No module named 'yaml' I have PyYAML, but... IDFK.

>>18226 Sorry to hear man, fuck. Take care of yourself.

>>18226 my condolences

>>18226 Oh man, that really sucks. Please take as much time as you need to grieve!

>>18226 Sorry for your loss.

>>18226 Damn, sorry to hear. Take all the time you need. >>18241 I understand why the PTR is the way it is, but I think that most anons wouldn't mind connecting to a central server which just spat out PTR tags for a given hash.

>>18226 Oh man. I'm so sorry to hear that, Dev. Stay strong, brother.

>>18243 Ignore this, I just wasn't thinking. Accidentally calling the py file directly. My condolences again, dev. Stay strong.

>>18226 F

Thanks everyone for the kind comments. There have been dozens of things to do, but the bulk of the immediate work is now done. My Dad's death was completely unexpected, so this has been an awful shock, far earlier than I ever thought, but we had a great relationship, and I have no big regrets hanging over me. For hydrus, I am missing work and keen to get back to it when my schedule is free again. More than anything right now, I am simply busy and tired. I won't rush things, but I'll have some empty days coming up over the next week and would like to catch up with my messages at least. Rather than put out an anemic release on the 21st, I'll work that day instead, let it all roll over, and be back to normal schedule on Saturday the 24th, with a proper full-changelog v500 out on the 28th. Thanks again!

>>18252 Nice to hear that you were good with your pops. Take all the time you need, lots of things to take care of when a family member passes. All the best to you and yours.

>>18252 No rush OP. Take your time.

>>18193 >>18194 >>18195 I also implemented a hacked nut counter feature; I added a separate 1-10 rating called "finish", increment it by 1 every time, and have a page that has a filter of: >system:rating for finish > 0/10 Though I sort by creator-series-title-etc in order to properly sort comic pages, I wonder if there's a way to sort by that and sort by nut rating at the same time. >>18079 This is EMBARRASSING but I cannot for the life of me figure out how to run Hydrus from a batch file (or shortcut) with a specific environment variable (99% of google results tell you how to change the env variable in Qt Creator). I could just go into Windows settings and add the environment variable right there, and it works just fine, but it may be nice for me to know how to make it app-wide. btw, you were right, the correct env var is: >QT_ENABLE_HIGHDPI_SCALING=0 I mention this because I also am having a lot of UI >100% scaling issues as well, but mostly in that the main window doesn't look right at 125% (media viewer looks fine!) Well actually I say "issues" and more like "it works correctly, I just don't like how it looks." At 125% the main window/media browser only shows about seven, chunky thumbnails instead of the normal nine (since the thumbnails are bigger, it shows fewer at a time), and the rest of the GUI is big and chunky (funny enough, while I cannot read Chrome pages at 100% which is why I bumped up to 125%, Hydrus at 100% looks completely fine on my monitor). Well, I was able to get it back to how it looked in Qt5 with the env variable and the media viewer still looks okay with the HIGHDPI_SCALING var set to 0, so I guess that this all works for me. I wonder if it would be worth adding to a help page or manual for future users. ps: hydrusdev your program has really improved my life, I'm so appreciative of your work.

>>18255 >the main window/media browser only shows about seven, chunky thumbnails instead of the normal nine Sorry, should've specificed I meant that it shows seven thumbnails per row at 125% with HIGHDPISCALING turned on, vs 9 per row with it turned off.

All the wheels are now spinning and I feel ok about the coming week. I'm less upset than I thought I would be. It just sucks, a lot. I've also got free time and energy now, so I'd like to be productive so I can feel better on that end too. I'll try to catch up with the whole thread, and since it is now bumplocked, I'll start the process to get it archived at >>>/hydrus/ and make a new one. I figure the hydrus user-base runs on the younger side, so most of you haven't lost a parent yet. The actual process of it has not been nearly as awful as I feared. I'd recommend you talk to your parents now while they are alive about what sort of funeral they eventually want, and make sure everyone in the family are all on the same page. You are going to be picking a casket, choosing music and flowers, making decisions on embalming and cremation and tissue donation, whether anyone is going to speak, if there will be a service and what sort, all the nitty-gritty 'someone has to decide, and now it is your turn' stuff. You can even plan your own, to relieve your children of the problem, which we are probably going to do for my Mum once things have settled down. Our family also sorted out wills a decade or so ago, and I can't recommend it highly enough. Spend a few hundred bucks now to save yourself a nightmare later. Anyway, if you are terrified of your parents dying, let me tell you it doesn't have to be the worst thing--it could be one of the most common experiences our ancestors had--but you have to be pragmatic and maybe have some difficult conversations now. >>18185 I fit this in to v499, I expect you already saw if you do this often enough. I went with 'clearing mass-pasted junk'. >>18186 The downloader forces some minimum and maximum time deltas in order to keep things working. If I remember correctly, for galleries' file search, it won't wait more than 30 seconds or so between page turns because if it obeyed normal bandwidth rules, it could be four hours between successive fetches, and if a lot of uploading happened in that four hours, the downloader would lose its place and stop since it would see stuff it fetched in a previous page. For standard booru page fetches, it also forces the raw file download a few seconds after the html/json page fetch because some sites have 'tokenised' file download links that time out after a minute or two. That said, check the options under options->downloading. Under the 'gallery downloader' and 'subscriptions' headings, you can set some global force-waits. Maybe if you bump those up to two minutes or similar, things will still work ok, but you'll get your slower access? Let me know that works for you. I haven't tested such slow access, so there may still be a hardcoded 30 second rule coming in or similar. If you click the little 'cog' icon when the job is waiting on bandwidth, it should tell you exactly what domains it is waiting on, which may help investigating what is and isn't holding things up. If we can pin down what doesn't work for you, I can expose these hardcoded waits in more options etc... and see if we can get you working. I also expect, one day, to export almost all the 'connection' and 'downloading' options to a domain manager that will track separate options for different domains, much like how the bandwidth rules work, so one day you'll be able to set a long delay for sank but a shorter default for all other sites. >>18189 'Not related' is a positive, permanent relationship, not a dismissal, and if I remember right, the way it actually applies in the database is fairly inefficient. I think it may require a connection for every pair combination in the group, so for a group of ten files, it makes I think 10!/(2!*8!), or 45 new database records. Since it is advanced and awkward, I don't think I expose it much to the normal user. In general, the 'not related' relationship's main use is to say that a potential duplicate, as you see in the duplicate filter, was a false positive. In general, false positives tend to be fairly rare. Are you finding you are getting a lot of them? Can you say what search distance you have searched? Could these be being found at, say, hamming distance of 10 or more? If you would like to blat a command that is more of a dismissal, like 'of these 10 files, if there are any potential duplicate relationships, then set those as false positive', then perhaps I should add that. Maybe that more human idea should be the general default of how I present this idea to the user, and I handle making the bullshit technical efficiency stuff in the background.

>>18190 >>18191 >>18192 I am going to figure out a nice technical solution to this in the future. The idea of going back to check for new metadata has long been a request, and I've been hesitant to do a quick bad job because, as said, I don't want to hammer sites or let someone who doesn't know what they are doing redownload 2 million html pages every month just to capture 5 new tags. As well as the rudeness of bandwidth, it also simply takes a whack of CPU to parse a document, and it adds up, so I don't want to add an equivalent CPU load to your existing downloader pages on top of everything. However, with modified date parsing done and now note parsing coming in, almost all of us long-time users want to do at least one slender re-fetch of pretty much everything. I am thinking of doing something like the file maintenance queue under database->file maintenance. You'll be able to set up any basic refetch rules and set which files to do (e.g. 'for every file I have a known url for, hit that url and update metadata' or 'for all my HF files imported before 2018, do it'), and then it will trickle that work out over weeks and months. The scale of some of these things is pretty crazy though--one file every ten seconds is 8,600 files a day, only 260k per month, when running 24/7. I've probably got 2.5 million downloaded files in my client, so that's most of a year to do one sync at that sort of decent pace. As always, I think we'll be wise to think of this work as a marathon, not a sprint, and recognise that we often can't keep up with our inboxes anyway, so the actual speed here isn't the largest issue. I sure don't process 8,600 files a day from my inbox, so I'm in less of a hurry. Just to address >>18190, I don't remember which tag came from which site, and I don't remember when tags were added to your client. Also yes, if this is important to you, I'm pretty sure you can wangle something with the Client API. Search your files, pull their known URLs, then trickle-queue those URLs into a special downloader page set to force a page fetch even if the file is already in db. (which is in 'tag import options' in help->advanced mode, if you want to play around with it, but be careful--it is powerful and dangerous, so don't set it as default). >>18193 Thanks, I remember talking to you about this before. I have limited support for this now, but not ideal support. Under file->shortcuts and the 'media actions' set, you can set a 'numerical rating increment/decrement command' for a shortcut, which would let you fill up a fixed number of stars/bubbles. Twenty stars in a row would probably look pretty stupid though, and it would obviously be capped at twenty. It might last you for the meantime though, and would be something you could copy across to a new system when it was ready. I like this idea a lot, and I am in a better position to work on new rating styles now. I will write it down and put it in my medium jobs queue.

>>18196 Thanks, I saw this just before 499 and I think I fixed it in that. Let me know if you still have any trouble! >>18200 Try double colon. It'll swallow the first and consider you are typing in a tag with empty namespace. "::)" for a smily face, I think some combination like that should work. I just tested the paste button in 'manage tags', and that'll accept ':)' and convert it to '::)' for you too, preserving what you actually pasted. >>18202 >>18204 >>18213 >>18243 >>18251 Thank you for these updates. I am increasingly confident that there is a dll problem in the build. It is part or combination of Qt, PyInstaller, and/or mpv. When I did my normal custom build of 499, I couldn't load the updated mpv for ten seconds without crashing, but the github build was fine. Most people seem to also have no trouble with it, but then some like you are getting similarly quick crashes, yet running from source is also fine. This suggests it isn't my code causing the crash, at least not directly, but some borked dll call somewhere. I don't have any excellent ideas, but since you have figured out how to run from source, please keep doing so for the time being. I always have to suggest that to Linux users, who have even work build compatibility problems. Unfortunately, because of the nature of python, getting crash debugging information is tricky. At my level, I never know about the crash and can't catch it or report it to log--the process exits immediately. It looks like you were able to recover some useful crashdump info in >>18204 . Almost all the workers are waiting there, but as you noticed, it looks like mpv was working on events. It is a shame that 499 gives you trouble too, since that is the new mpv-2.dll, and I had hoped it would be more stable. I'll keep fighting on this. I have to do some mickey mouse shit in order to get mpv to work at all and not crash immediately, so I will explore around there. Maybe I am allowing mpv's event processing to touch UI elements when it shouldn't. Please keep me updated, your work here has been helpful. >>18202 If you would like to try running from source, it takes a little bit of work, but the help is here: https://hydrusnetwork.github.io/hydrus/running_from_source.html . I'd be happy to help, too. A simpler thing to try in the meantime might be swapping out the 'mpv-2.dll' in your install dir for the 'mpv-1.dll' from a recent older version (v497 etc...). You probably have both in your install folder now, so try renaming mpv-2.dll to mpv-2.dll.old. Then boot the client and check help->about. It should say an older mpv api version. Fingers crossed, that crashes less for you. Otherwise, please try v500 and let me know how you get on. I want to get this all sorted if I can. >>18209 Check the booru/site itself. Boorus tend to have some metatags you can insert into the query to do some neat stuff. Like this: https://danbooru.donmai.us/wiki_pages/help%3Acheatsheet If you ctrl+f 'order' in that, there are several options. If you added 'order:id' to your search, I think that'll do oldest to newest. Most boorus run on similar or forked engines, so parts of that cheat sheet will work in many places.

>>18211 >>18212 I'm afraid I am not expert enough about setting up sites and forwards these days to talk too cleverly. I'll say the nicest way to test is just to load the server address into your web browser. As an example, check here: https://ptr.hydrus.network:45871/ That is the PTR. It has an expired cert, but if you let your browser go through anyway, you'll get the landing page with an ASCII lady. My guess is that because hydrus's https uses a self-signed certificate, that's what's causing the trouble here. I think the http/80 result is giving you an error because your client's network engine is probably trying to access it using cleartext but it is failing. The server is not clever enough to upgrade http to https, at least I have no tech for that, so that's probably the nature of the weird error there. The hang I am not sure about, but if you try the same basic query, https://hydrus.mydomain.com:443, in your web browser, see what happens. You might get a proxy error page or something. It might also be that 443 is a protected port for the proxy service, with special hardcoded rules? Not sure. Maybe a web server port has some special security rules for ssl that I don't or can't obey up in duct-taped 45870. I specifically tell hydrus not to verify https traffic across the hydrus network itself (because of the self-signed certs), so the hang is even more confusing. Yeah, my guess is the proxy service is unhappy/confused about ssl. I'd recommend to take the http map off, since that'll never work afaik. I know some guys on discord have a lot of experience setting this stuff up, for the PTR and other projects, so if you can stomach that, you might find more luck looking for help there. I know some guys had to set up some kind of flag for 'don't sperg out that the https certificate is self-signed'. Also, if you know how, in your web browser, if and when you get the ASCII lady to show up, check the http response headers. I know some proxy services will overwrite the headers here, although I guess those would be ones you had to share the ssl certificate with previously. >>18214 Just a side thing, use 'code' with square brackets and an html tag style slash to close the block, as at the bottom of here: https://8chan.moe/.static/pages/posting.html >>18215 Thank you for this report. I am sorry for the trouble. It looks like the new mpv is causing a variety of issues. If it is convenient, could you try extracting the Qt6 version on your desktop? Just make a fresh install of Qt6 499 and try importing a video to it. Does it play? If it does, it could be Qt5 doesn't work well with the new mpv. If it doesn't, there's a deeper mpv problem going on, and I'll ask you to hit help->about, which should make a popup with more detailed information about why mpv could not load. If nothing works, you may be able to update to 499 but delete the new mpv-2.dll that comes with it. The old mpv-1.dll that is probably still in your install folder should be fine, but if it is not, that is also useful information to know.

>>18216 I haven't done the big change on the Linux side just, so this may be placebo, but I've also done some other video/mpv work recently that may have reduced some lag for you. As I asked in the v499 changelog, some Linux users tested out the new python-mpv wrapper, and they said it works well, so I will be updating it in the Linux build for v500. I think you'll still see 1.109 for now, but when libmpv1 either in my build or your system (through apt-get) gets updated, the new python-mpv should handle it well. >>18217 Damn, thank you for this report. I am sorry for the trouble and will check this out. I did work on that loop-checking logic recently, I thought to improve things and help bunch stuff together for the janitors, so perhaps there is a new bug in there. >>18218 You know I was reading this recently https://support.nordvpn.com/General-info/Features/1845333902/What-is-Meshnet.htm , which as I understand it is basically user-friendly hamachi. If the other vpn providers soon offer the same tech, and consumers get access to easy virtual local networks, some of our hydrus-specific pains is the ass may evaporate. All the shit about setting up proxy forwards and self-signed ssl certificates and things disappears if the secure network side of things is handled by a vpn provider and your phone thinks it is talking to 192.168.x.x. That said, if you are already on the same network, your best bet is just to boot up the Client API and try out Hydrus Web. If you already have 192.168.x.x:45869 visible and just want to sit on the couch with your tablet and browse things, this is possible right now without too much strife: https://hydrusnetwork.github.io/hydrus/client_api.html >>18219 Probably early next year. I'm going to start with the very easy case of jpeg+png exact pixel dupes (keep the jpeg), just to get a skeleton of an auto-dupe-filter started, and then flesh it out with cleverer rules from there. Everything will be completely optional, default off. My dream is that in five years we have all sorts of tech making weighted decisions about dupes, and 95% of stuff is handled without you ever seeing it, including immediately on import. >>18220 Maybe. We've played with this tech before. A legacy system called 'file lookup scripts' allows you to do this on a per-file basis in manage tags, but I think you have to turn it on under options->tag suggestions. If I do it, it would hook into the slow-burn system I describe here >>18258 since the same bandwidth and workflow concerns apply. That said, I've dragged my feet on this general question a bit since there basically isn't a 'nice' technical way to find tags for files, which is exactly why I wrote the PTR. The PTR has proved so successful it is now too big for many users, which is its own issue, but in general if you want to share file tags, most sites just aren't optimised for it, and you are downloading kilobytes of json or hundreds of kilobytes of html for twenty five words. Whatever answer we figure out for an automatic system is going to be a little ugly and slow, no matter what. But yeah as >>18222 says if you are willing to put the work in, the Client API let's you wangle whatever you like. I don't know their explicit rules, but if you have a premium account for sank I expect they let you do as many md5 lookups as you want as fast as you want. I know that most explicit lookup sites like iqdb or saucenao put a good limit, something like 100 lookups a day, which works for humans but won't work for an automatic system.

>>18221 >>18222 I am very sorry, I think you have overwritten your database, yes. You still have your actual media, the jpegs and so on, but your archive record, known urls, the session and subscriptions, all the stuff you see in the UI, has probably been overwritten. You probably already have, but I recommend you have a very good think about if there is any chance an old copy of your database might sit in your recycle bin or an old usb stick somewhere. If there is one, we can probably stitch a rollback together. If not, you may be looking at starting a new client and then importing your old install_dir/db/client_files structure. You would be looking at the 256 'fxx' subdirectories in that folder. For the backup situation, I am sorry. I know how it feels to lose your stuff. Although it is a shame, it is usually emotional kicks like this that ultimately give you the motivation to figure out a good backup solution in future. You don't want to lose shit like this again, so you put the time and money in in future. You don't have to do it today, but if you have a planner, make sure in a week or two that you come back and plan a proper backup routine. Not just for hydrus, but your documents and writing, any art or programming you do, anything digital, so if your machine blows up or your place burns down you still have a copy on a USB stick in your backpack, whatever works for you. My backup help is here: https://hydrusnetwork.github.io/hydrus/getting_started_installing.html#backing_up And a special message for you is here: https://hydrusnetwork.github.io/hydrus/after_disaster.html I'm happy to help with recovery or setting up your future backup, just let me know. >>18225 Thank you for this report. I will investigate this. Unfortunately, crashes (as in the program halts and exits immediately) will not record any information in the log, but if the program simply halts and does not respond, there may be something in the log as >>18236 says. As you are a Win 7 user and Qt6 will not work for you, you may be looking at the option of running from source soon. The users in this chain >>18213 found that running from source reduced their crashes significantly, so if your problem is similar, this may be something to think about. >>18234 >>18235 Thank you for this report. I am sorry for the trouble. It looks like there are several odd problems here. It is useful to know that 498 improves things, so I may have, while attempting to reduces crashes in my v499 work, actually made things worse for some users. Can you try something for me? Try extracting a fresh version of v499 to your desktop, boot it up, and only import some jpegs. Is that stable? If you then import some videos and load them up, does it suddenly become unstable? The other big change in v499 is a new version of mpv, and several users are having crashing problems with that. A crash can happen minutes after seeing something in mpv, so I would like to figure out if your problems were actually time-bombs planted by casual mpv loads earlier on. >>18241 >>18248 In doing the janitor workflow improvements to cap out this year, I'm hoping to attach a tag filter to the PTR. The janitors will be able to say 'no filename: tags' and similar. As I deploy that tech, I'll be figuring out efficient database-level scans of tag filter rules, which means I'll hopefully be able to deploy the same thing clientside and let users say "hey I want to process the PTR, but only get me 'series', 'creator', and 'character' tags". This may be a nice way to get lean versions of a PTR process. We did some pie charts a long time ago, and the PTR is roughly 33% each of: - series/creator/character - unnamespaced tags - other namespaces So if you only wanted S/C/C, you'd be 'just' a 600 million mapping process and a 20GB db space investment. At least ideally--I don't know how the db tech will work yet, but I'd like the ability to skip the shit you don't want. >>18255 >>18256 No problem. I don't know how the hell .command files do it, but if you are working old school .bat like I do, go: set QT_API=pyqt5 client I had to figure it out for that QT_API stuff when I was testing Qt6 and needed a way to select different libraries to load. You have to do it with a batch, as far as I could find a shortcut can't do it in the one step. So for you I think you are going: set QT_ENABLE_HIGHDPI_SCALING=0

[Expand Post]

client Yeah, I think this should be added to the help. I'm happy that I'm obeying UI scaling rules 'better' now, but I personally hate how all applications look at >100% so I have to run all my monitors at 100% anyway. Since you mentioned Chrome, when I was a dumbass nuking my eyes on a 17" 4k laptop screen at 100%, I used an add-on on my browser to force some weirdass zoom rules, like text was zoomed at 150% but images were still 100%. Maybe a similar thing is still available these days? As a side thing, I'm hoping in the future to have prettier thumbs at >100% zoom. There are technical reasons that I have to do some bilinear scaling for now, so they get a bit gritty, but I'll work on the code over time and divorce image size from virtual display size and that should let me generate actual pixel-for-pixel sizes that look good.

New General here: >>>/t/9763 This one should be migrated to /hydrus/ soon. Thanks everyone!