I had a mixed week, but I got a couple of neat things done. I fixed a handful of bugs, wrote a 'tag actually exists here' filter for tag siblings/parents export, and added local file/thumbnail path fetching to the Client API.

The release should be as normal tomorrow.

Hi dev, many moons ago back in the double digit versions I asked if there was a view to see all tags, or a count of the number of unique tags. At the time you'd mentioned that the database wasn't set up in a way that made that operation practical, and recently I've been paring down and standardizing some old tags (like starting in maybe 2016 old) so I thought I would ask if anything has changed with updates on tag meta-management.

I had a good week. I did the background work I wanted to do, and for the release I've got a variety of quality of life bells and whistles to roll out. Nothing huge, but a bunch of little UI improvements.

The release should be as normal tomorrow.

>>1695
Not really, I'm afraid. There's still no 'tag wiki' in hydrus, like you see in the boorus. There's some new ways to search/list all tags, or all tags of a certain namespace, under tags->manage tag display and search, so you can straight up search for '*' now, but no proper paginated tag browser.

There's much better Client API tools, though, including autocomplete search, which would allow you to inspect this stuff more programmatically or make your own tag wiki: https://hydrusnetwork.github.io/hydrus/developer_api.html#add_tags_search_tags

Maybe that would allow you to do something of what you are thinking of here. For the most part though, hydrus is still optimised to ingest as much as possible, and the PTR has like fifty or a hundred million unique tags (across 2+ billion mappings), so the various problems of presenting the 'hydrus taglist' in a form a human can handle are all the more difficult.

https://8chan.moe/t/res/15721.html#16076
> If the URL is already on a file, does pic related do it? Or are we talking file urls that might not be in this menu list?
I get the URL from a website, but I cannot download it with Hydrus, and I don't know if the file is already in Hydrus, but I want to find it there if it is.

Didn't "tag display sync" (tags - sibling/parent sync - review current sync) remember the active tab? I've been having to switch it every time for a couple of versions now.

Hey, I'm pretty sick, so no release tomorrow.

v589 should be out on the 11th. Thanks everyone!

>>1689
Ah I see, thanks. You might like to keep a page open, or save a favourite search, that has one 'system:url = http...' system predicate, and then when you want to do this search again, just open up that page and shift+double-click that predicate to edit it and paste your new URL in. Maybe that's quicker than regenerating it every time?

Another option, if you are ok doing a little bit of scripting, is asking via the Client API. You might be able to rig a .py script or something that you can paste an URL into to get a quick yes/no answer.

https://hydrusnetwork.github.io/hydrus/client_api.html
https://hydrusnetwork.github.io/hydrus/developer_api.html#add_urls_get_url_files

>>1690
If it doesn't, it should. I will check it out, thank you for the report!

>>1691
>Hey, I'm pretty sick, so no release tomorrow.
Hope you are getting well!

>shift+double-click
Didn't know that. https://hydrusnetwork.github.io/hydrus/getting_started_searching.html#editing_predicates
Yes, that's quicker, thanks.
I hadn't been using saved searches much, because I wanted to append more than replace.

>>>1690
>If it doesn't, it should. I will check it out, thank you for the report!
That made me rename my favorite tag service so it first everywhere.


I deleted a couple file services, so some watchers got "nothing", and the error message only said that there was data missing (and maybe, in the traceback, that it is a file service name), not where.

I had a good couple of weeks. I mostly worked on code cleanup and optimisation, so large clients should feel snappier.

The release should be as normal tomorrow.

>>1692
I've got that dialog remembering tag service for tomorrow.

>I deleted a couple file services, so some watchers got "nothing", and the error message only said that there was data missing (and maybe, in the traceback, that it is a file service name), not where.
Interesting, I'll check what's going on here. I would have thought it should raise a nice clear error if there is no import destination. Or maybe halt all work.

I had an ok week. I finished the list rewrite, so all multi-column lists across the program now populate and sort far quicker, particularly when they have tens or hundreds of thousands of items, and I fixed some bugs.

The release should be as normal tomorrow.

I had an ok week. I was not able to finish the list rewrite I had planned, but I did clear a mix of small jobs.

The release should be as normal tomorrow.

I had a great week. I fixed some bugs, finished some advanced multiple local file service features for the Client API, and got siblings and parents loading faster, particularly for the new dialogs.

The release should be as normal tomorrow.

>>1674
I also can't guess what in my environment would only impact PTR requests. Some weird firewall rule? Something I did to fix Hydrus years ago that is now breaking it? I'm not even 100% sure I'm on the same windows install, and I would The issue persists on a VPN, so it shouldn't be about my local network.

I'll look into it.

I had an excellent couple of weeks. The manage tag siblings and parents dialogs now load and operate quickly, even when the underlying service has hundreds of thousands of pairs. I also cleared a bunch of normal small work.

The release should be as normal tomorrow.

>>1674
>>1675
>>1676
Yeah, I think you are right that this is probably something outside of hydrus, and/or something related to some borked dll somewhere.

Since it specifically cites '_ssl.c:1006' in the error, I'm pretty sure that is a .pyd file (probably _ssl.pyd either in the install dir or your python environment), or _perhaps_ some Windows dll it is calling. Since you can fetch normal https with valid certificates fine, I'm guessing this is happening because of some obscure security policy that is set in your Windows or something that requests (or the ssl pyd somehow) is force-applying despite me saying verify=false, or indeed if there is some init that happens despite the verify=false and that's triggering something else. I'm afraid I am not expert enough in this to talk too cleverly though.

Let me know what you find out! Fingers crossed, this fixes itself anyway when the guy who hosts the PTR refreshes his cert.

P.S. This is a bit in the weeds, but this is as best as I can immediately see where it is working with the 'verify=False' at the coalface: https://github.com/psf/requests/blob/79b74ef704dc0d804937c0d015c5e9c3b02b79bd/src/requests/adapters.py#L111
There's some other stuff in that same file, including line 409, where perhaps there is a route for a non-nothing cert policy to be set despite verify=False. I remembered that 'requests' is build on urllib3, so perhaps that can set a different cert security policy here.

Of course the correct answer, truly, here, is for me to write a proper management system that saves self-signed certs and lets users approve them manually, and then I'd be setting the cert to verify itself or whatever here, instead of False, although maybe that would still fail on an expired.

>>1677
As a follow-up, I was just looking through their docs--I don't suppose you have a cert file set in your environment, do you? I wonder if requests or urllib is pulling that as a fallback and since that value now isn't initialising as None, it leads to the cert policy being 'use the one from the environment'? I think it would be REQUESTS_CA_BUNDLE or CURL_CA_BUNDLE, or perhaps something similar? It would presumably have a value that pointed to a local cert file in your system dir somewhere.

>>1678
You got it, CURL_CA_BUNDLE was set by Postgres. Seems to work now. Thanks!

>>1679
Hell yeah! Glad we could sort it--interesting problem!

I had a good, simple week. I added some commands to the Client API and cleared some bug fixes and UI improvements. An issue that was causing redundant file downloads on Pixiv is fixed.

I had an ok week mostly cleaning code. There's some new settings for the command palette, and the 'manage times' dialog gets the ability to set times to multiple domains at once.

The release should be as normal tomorrow.

I had a great week working on UI fixes and quality of life. There's a new test panel for sidecars and the colours in the options->colour panel can finally be set via stylesheet.

The release should be as normal tomorrow.