/hydrus/ - Version 568

Name
Email
Subject
Comment
Password
Drawing	x size canvas
File(s)	Drag files to upload or click here to select them
Spoiler

Version 568 Anonymous Board owner 03/27/2024 (Wed) 23:13 Id: 6ee685 [Preview] No. 1621

https://youtube.com/watch?v=PgqmqeH0iDs [Embed]
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v568/Hydrus.Network.568.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v568/Hydrus.Network.568.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v568/Hydrus.Network.568.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v568/Hydrus.Network.568.-.Linux.-.Executable.tar.zst

I had a good couple of weeks mostly figuring out better behind-the-scenes URL handling.

Full changelog: https://hydrusnetwork.github.io/hydrus/changelog.html

urls

For normal users, tl;dr: URLs better now, you don't have to do anything.

I made a dumb mistake when I first created the downloader engine in how I handle URLs behind the scenes, and today it is fixed. You don't have to do anything, and you shouldn't see any big changes, but in general, URLs and query texts with unusual characters should work better now. You may also notice a URL in the file log or search log will appear one way, e.g. with japanese kanji, but when you copy it to clipboard, it is all encoded to %EF kind of stuff--your browser address bar probably works the same way. It should just mean things copy between your hydrus and other programs with fewer hiccups.

If you regularly use some very odd URLs or downloaders, there might be a hiccup or two. A file that relies of strange encoded characters in its known urls might redownload one time if a subscription hits it, or one extremely strange query text (it'd be a single tag query that has a % character somewhere in the middle) might need to be renamed to %25. If you have a crazy custom downloader that relies on %-encoding tech, please pause it before you update, and then do a test afterwards--it may be the hack you added for the old system is no longer needed. In any case, let me know how you get on, and if we run into a problem with a certain downloader, we'll fix it together. Overall, I'm hoping that working with encoded URLs exclusively will make more complicated downloaders easier to figure out in future, rather than having to fight with odd characters all the time.

I decided to cancel this release last week because I wasn't confident on how I was handling the advanced edge cases of encoding here. I am happy I did, because while all the 'just download from a booru' style downloaders (like the defaults) were fine, the most experimental downloader situations (that e.g. needed encoded parameter keys) needed more work. If you are a downloader maker, then you will be in the guts of these changes, so please check out the changelog. There's new UI in 'manage url classes'--path components and parameters now have their own edit panels with linked text boxes that show the normal and encoded values of the stuff you are entering, and there's also new 'ephemeral token' tech that lets you decide in what ways undefined parameters should be clipped before the URL being sent to the server. The idea of the 'request URL' being different to the 'normalised URL' is broadly elevated and exposed across the program.

Anonymous Board owner 03/27/2024 (Wed) 23:15 Id: 6ee685 [Preview] No.1622 del

other highlights

I also added a 'tag in reverse' checkbox to the new 'manage tags' 'incremental tagger' thing. It adds tags like 5, 4, 3, 2, 1 instead of 1, 2, 3, 4, 5.

And all new system:url predicates have new labels. They are all a bit simpler, and they should copy/paste into the system predicate parsing system. All existing system:url predicates still have their old labels, so if this is a big deal, you'll want to recreate them and re-save your session/search.

Thanks to a user, the new docx, xlsx, and pptx file formats get some nicer thumbnails and a little metadata. It should all recalculate soon after update.

The Client API is now more careful about which files you can undelete, and it also now lets you clear file deletion records.

next week

I want to put proper time into getting a 'future build' working. Last time I tried, I ran into some technical problems related to the newer libraries I wanted to bundle, so I'll see if I can fix it all and have a test release for people to try. Otherwise, I just want to clear out some small jobs that this URL work boshed.

Anonymous 03/29/2024 (Fri) 02:03 [Preview] No.1623 del

Anyone knows if I can download files (through url downloader, non-booru site) whilst keeping their original filenames somehow (as tags or whatever)? And in a way that I can have the files renamed when exporting? I found plenty of places saying it can be done but I've tried messing with the tag import options among others and nothing seems to work.

Anonymous Board owner 03/30/2024 (Sat) 20:10 Id: 5e2328 [Preview] No.1624 del

>>1623
Servers typically give that filename in the 'http header' of a file download. Hydrus generally does not parse this in the same way that your browser would and does not push it into the general metadata pipeline of a file import, so I'm afraid the only way you can figure this out is to parse it from the html file or similar, as you would for other metadata like tags or related URLs.

In general, also, most downloader makers do not parse the filename. The imageboard watchers like the 4chan parser does parse for the filename, and gives it a 'filename:' namespace. By default, I have these set not to add in the 'tag import options' for watchers, since most users don't want them.

If you feel clever and brave, you can try to add a 'content parser' to a downloader you are interested in to try and grab filename from the boorus you like, but beyond that, I'm sorry to say I don't have a good answer for you. I've thought a few times about making a 'filename' tag service that remembers hard drive import filenames, and could potentially get server-set filenames too, but every time I return to the idea, I realise it'll probably just get overwhelmed by 'Image.jpg' garbage that isn't typically useful.

Although I can't give you a nice answer, you might like to read my FAQs on this question, just so you see better where I am coming from and why I don't want to put much time into this:

https://hydrusnetwork.github.io/hydrus/faq.html#filenames
https://hydrusnetwork.github.io/hydrus/faq.html#external_files (somewhat related)

And if you would like to dabble with making/editing your own downloaders, check out the help here:

https://hydrusnetwork.github.io/hydrus/downloader_intro.html

Anonymous 04/02/2024 (Tue) 07:49 [Preview] No.1625 del

I'd seen those pages already, thank you. I understand about filenames but this time I really needed them. Over 90,000 work-related images that were numbered in a specific order, and that ordering had to be kept. I've found another solution but thank you for your work and your reply.

Release Tomorrow! Anonymous Board owner 04/03/2024 (Wed) 01:51 Id: 35070d [Preview] No.1626 del

I had a good week. I fixed a bunch of small issues, and I figured out the problems with the 'future' build, so I'll also have a special version for more advanced users to test out.

The release should be as normal tomorrow.

>>1625
Great, I am glad you found a solution!

Posting mode: Reply