/hydrus/ - Hydrus Network

Bug reports, feature requests, and other discussion for the hydrus network.


New Thread
X
Max 20 files0 B total
[New Thread]

Page: Prev [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] Next | [Index] [Catalog] [Banners] [Logs]


https://youtube.com/watch?v=Poii8JAbtng
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v570/Hydrus.Network.570.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v570/Hydrus.Network.570.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v570/Hydrus.Network.570.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v570/Hydrus.Network.570.-.Linux.-.Executable.tar.zst

I had a good week clearing simple jobs. There's nothing too clever, just a bunch of little fixes and improvements all over.

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

highlights

All the tooltips in the program now wrap into a neater multi-line block. No more super long single-line tooltips!

The 'open' submenu when you right-click on the thumbnails or the media viewer has been cleaned up and plugged fully into the shortcuts system. It now looks and works exactly the same in either the thumbnail or media viewer view, and 'open file in web browser', 'open files in a new duplicates filter page', are added to the 'media' shortcut set. What was previously four 'show similar files: 0 (exact)' shortcut commands is now merged (and will be automatically updated in v570) into a single 'show similar files' command that lets you set any distance.

I fixed a stupid thing in manage tag siblings/parents that was too-frequently making it so when you spammed a bunch of pairs at it in one go, it wasn't allowing deletes (it was activating the 'only add' functionality). Should be fixed now, and it'll ask to petition pairs amidst adding others, but let me know if this changes your regular workflow annoyingly. These dialogs are way overdue for a complete overhaul.

I fixed some more URL encoding issues with some help from users. If you have a clever downloader that broke in the past couple of versions, sorry! Try it again, and let me know how it goes.

next week

More of this. I'll clean up the 'share' submenu like I just did the 'open' one, too.

Last week's test 'future build' seems to have gone well, no significant issues reported, so I will integrate that into the main build. Windows and Linux users who use the extract builds will have special 'clean install' instructions for v571, but I'll explain it all super easy when we get there.
I had a mixed week. I did some boring stuff, some quality of life, and folded the 'future build' updates into the main release. Users who use the manual 'extract' releases will have special update instructions.

The release should otherwise be as normal tomorrow.



https://youtube.com/watch?v=rAbVhoeWcAs
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v569/Hydrus.Network.569.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v569/Hydrus.Network.569.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v569/Hydrus.Network.569.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v569/Hydrus.Network.569.-.Linux.-.Executable.tar.zst

I had a good week mostly fixing small things.

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

highlights

I fixed some issues with last week's URL improvements. It is mostly advanced stuff, so if you are a downloader maker, please check the changelog.

For regular users who download from certain sites that can produce multiple files from one post (I am told that Pixiv was not affected, but Inkbunny was), I am afraid I made a stupid mistake that meant only the first file of those posts was being downloaded. This is now fixed, so if this affected you and you have a bunch of subscriptions, let's fix it: once you are in v569, load your subscriptions up and sort their queries by 'last check time'. Select what has run in the last week, copy the query texts, and then paste them into a new gallery search page with the file limit set to something like 50. Your client will go over what was missed and fill in any gaps.

I harmonised some search logic related to 'system:duration = 0', '<1', '!=0', and other variants around the zero edge case, for duration and the other simple predicates I updated a while ago. When I first wrote this, I tried to thread a needle of logic where in some cases it would return files with no duration and sometimes it would not, but it all ended up a mess, so, from now on, searching for any simple quantity that would include '0' will now include any file that has no value for that property. (e.g. an mp3 has no width, so now system:width search**. It wasn't saving right, sorry for the trouble!

future build

I have a new 'Future Build' ready. This is a build the same as the one above, but it uses newer python and libraries. We do not know if those libraries cause any dll conflicts on any OSes, so if you are an advanced user and would like to help me test it, please check out this link:

https://github.com/hydrusnetwork/hydrus/releases/tag/v569-future-build-1

next week

More small jobs. If I can, I'd like to focus on some UI quality of life.



https://youtube.com/watch?v=PgqmqeH0iDs
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.
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.

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.

 >>/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&#95;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&#95;intro.html

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.

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!



https://youtube.com/watch?v=PlvK2pabBqI
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v566/Hydrus.Network.566.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v566/Hydrus.Network.566.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v566/Hydrus.Network.566.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v566/Hydrus.Network.566.-.Linux.-.Executable.tar.zst

I had a good week. The long-awaited incremental tagger is ready, and the program supports some more document types. You will get a yes/no on update, but it isn't a big deal.

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

incremental tagger

When you open the manage tags dialog on several thumbnails, it now has a '±' button that lets you tag the files 'page:1', 'page:2', 'page:3' and so on. You can set the namespace (or no namespace), the starting point (so you can start at 'page:18' if you need to), the 'step' (so you can count by +2, or even -1 to decrement), and even prefix/suffix for the number if you need to decorate with 'page:x (wip)' or something.

I'm quite happy with how this worked out. There's some live text that gives you a preview of what's about to happen, so the best way to get to grips with it is to play with it. Just click and poke around, and let me know how you get on. Namespace will be remembered between opens, and if the first file in your selection has a number tag for that namespace, it'll set the 'start' position to that value. If you are setting page tags to a bunch of chapters, or gaps in a larger body, a bit of prep/overlap may help things here.

We've wanted this for years and years, and while I'm not expecting the program to handle paged content beautifully now, this is a decent step forward.

docx and friends

The document types .docx, .xlsx, and .pptx, which are the newer Microsoft Office 'Open' formats, are now recognised by the client. These are secretly zips, so there's a chance you have some in your client already. On update, you'll be asked if you want to scan your client's existing zips to see if they were really one of these. You probably don't, so it isn't a big deal, but if you think you do, hit yes and they should appear.

next week

Cloudflare are rolling out some annoying new cache-optimising tech that is causing file dupes, so I need to work on URL handling so we can patch the most-affected sites.
I had an ok week. I reworked some URL handling in ways that are mostly important behind the scenes and cleared some small jobs. It'll just be a simple release.

The release should be as normal tomorrow.


I had a great week. I tightened up the URL storage/handling improvements that I was not confident in last week, so I am very happy to put out the release tomorrow. There are also advanced new tools for downloader makers for handling 'ephemeral token' parameters along with new quality of life UI in the manage URL Classes dialog. For normal users, there are also several bug fixes, file handling improvements, and a couple little things in system predicates, emoji tag presentation, and reversed tags in the new incremental tagger.

The release should be as normal tomorrow.



https://youtube.com/watch?v=lgpD6OsHCKU
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v565a/Hydrus.Network.565a.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v565a/Hydrus.Network.565a.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v565a/Hydrus.Network.565a.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v565a/Hydrus.Network.565a.-.Linux.-.Executable.tar.zst

I had a simple week. Lots of small changes today. The update step may take a couple of minutes.

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

highlights

You are going to get a couple yes/no dialogs on update this week talking about deleting some mis-parsed URLs. If you do not manually store weird data in your 'known urls' store, just click yes. If you have lots of URLs, the work will take a couple of minutes.

options->sort/collect now has four different default tag sort widgets! You can set the default tag sort for search pages, the media viewer, and the manage tags dialogs launched off them.

There's a new 'media' shortcut action 'copy file known urls', that copies all the known urls of your current media selection.

Sidecars set to import to file notes now have an optional 'forced name' field, so if you ave a .txt file with only note text, no name, you can now force it. Some of the UI is less jank here too.

The tag filter UI also got a little polish. There's less logic jank, better labels and tooltips, and you can now copy listed namespace entries to the clipboard and get something you can paste back in elsewhere.

next week

I did not get to the manage tags dialog incremental tagging thing this week, so I'll try again.
I had a good week. The 'incremental tagger' system is working, allowing you to tag page:3, page:4, page:5 ... page:17 and similar to a selection of files, and .docx files are now importable.

The release should be as normal tomorrow.



https://youtube.com/watch?v=Oo0o84-TJTU
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v564/Hydrus.Network.564.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v564/Hydrus.Network.564.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v564/Hydrus.Network.564.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v564/Hydrus.Network.564.-.Linux.-.Executable.tar.zst

I had a good week, several system predicates have better range-based searching.

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

highlights

The system predicates for width, height, num_notes, num_words, num_urls, num_frames, duration, and framerate now support two different kinds of approximate equals (≈): absolute (±x), and percentage (±x%). Previously, the ≈ secretly just did ±15% in all cases, but now you set how and how far they go.

Also, any 'system:framerate' predicate that was '=' will now be converted to ±5%, which is what it was secretly doing before, and any 'system:duration' '=' predicate will also be converted to ±5%, which is what it really should have been doing before. 'system:duration' also allows hours/minutes input, for longer videos.

This predicate overhaul was an important cleanup job, replacing a ton of hacky ancient code with something that is easier to update and maintain. I've collapsed all these preds down to a lot of shared UI and logic, so let me know if there are any display/search quirks, but once we have it nailed down, I hope to replicate this work for the more complicated system predicates.

I reworked what 'Space' does in the media viewer by default. I am updating existing users too, so you'll probably get a little popup about it when you update. Essentially, if you are still on the default shortcuts, Space will now only send 'pause/play media'. It no longer does 'yes' on the archive/delete filter or 'this is better' on the duplicate filter. If you want to go back to how it was, sorry for the trouble--hit up file->shortcuts to set it back.

Thanks to a user, space also does a new 'Quick Look' for macOS users on thumbnails. Try it out! If you are a 'running from source' macOS user, make sure to rebuild your venv this week, or it won't work!

next week

I'd like to figure out incremental tagging on the manage tags dialog, so you can select 20 files and tag them page:7 through to page:26 in one step. Let's see how it goes.



thumbnail of FA_Compatibility_v4.1
thumbnail of FA_Compatibility_v4.1
FA_Compati... 1
(829 B, 0x0)
Hey,

Since my last message, I recently had time to work with Hydrus, and I developed a semi-functional parser for my HTML files. However, I don't want to include the description string in the tags, so I need to remove it. However, I'm not sure how to do this. I assume that it has something to do with the "string selector/slicer" component, but I'm not sure how that component works. I managed to do an incredibly crude filter by regex filtering by ^[^<]+$, which blocks the < in html tags, but this will presumably fail for any description that doesn't include html tags, for whatever reason. I would really appreciate your advice on this. If you need to see my (bad) code, I have attached the code to copy as a text file.

Thanks!

Ps: I can't import sidecar parsers through pngs, as the file selection dialogue doesn't show png files, just folders. Is there something I'm doing wrong?
thumbnail of Screenshot 2024-02-24 132030.png
thumbnail of Screenshot 2024-02-24 132030.png
Screenshot 2024-02-24... png
(46.14 KB, 1454x987)
Yeah, this is tricky. I still think your best answer is to wait for me to implement a proper xml/html parser for sidecars, or do the parsing yourself in an external script (e.g. with python) and then convert your html into nicer .txt files that hydrus can suck up easier. You could also filter your undesired tags better there.

If the 'description' string is always in the same location, and that location is always the first or last index of your list of strings, then the 'string selector' might help. It does list slicing like in programming, if you are familiar, like "my_list[4:6]". If you aren't familiar with that, or the description is in the middle of the list here, you are correct in trying a string match, which is basically a filter.

If the description line has a classname in the html, you might be able to exclude it with a string match before you Split/Convert all the html garbage away.

I am not totally sure what you mean by being unable to import by pngs, but if I click 'import->from pngs' (pic related is from the 'sidecars' tab of the 'add tags/urls with the import' dialog after you drop some files on the client), I get a file dialog that allows me to import a png like this. Do you get different?

thumbnail of highdiskusage.png
thumbnail of highdiskusage.png
highdiskusage png
(202.89 KB, 1600x900)
thumbnail of pngparserbug.png
thumbnail of pngparserbug.png
pngparserbug png
(128.77 KB, 1600x900)
Hey,

Sorry that it took me a while to respond. I figured out a solution to my html parsing issue. Apparently, the parser first splits sidecars by the specified string, then passes the split strings onto the postprocessor, breaking the regex splitting I used in the process, before then passing it back to the parser, where it is then split by the string again and saved. I figured out a solution to this problem, but thanks for your help anyways. To answer your questions about the parser import, I am using Linux Mint 21.3 Cinnamon with qt6.5.2, rather than windows, and the pngs do not appear in the window. Maybe the apis are different? I attached a screenshot of this, if that helps.

Thanks for your help!

Ps: why is this client writing TBs of data to my ssd while processing the PTR? I understand if it writes a lot, but multiple TBs (according to some math I did, I haven't gotten that far yet, just ~750gb) still seems a bit excessive. I attached a screenshot of this too.



 >>/1610/
 >>/1611/
 >>/1612/
Yeah, the write is most likely temp storage. I've heard that in some situations, the actual amount written to disk is less since some temp-file magic means some of the shortest-lived data is purged from the write cache before it can actually be committed, but I don't have good numbers on the topic.

The PTR does a lot of database work. The no_db_temp_files parameter will reduce it by a good amount. Not sure how much, but it would reduce it.

Increasing db_transaction_commit_period may also reduce it, I think, since it will reduce the commit frequency (at the cost of increasing per-transaction size, which will strain your temp folder and slow processing time).

A user also wrote this document with a lot of related info, if it helps: https://hydrusnetwork.github.io/hydrus/Fixing&#95;Hydrus&#95;Random&#95;Crashes&#95;Under&#95;Linux.html

I'm not a Linux expert myself, so I can't talk super confidently here. Let me know how you get on!



https://youtube.com/watch?v=XXlzWhBvYwg
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v563/Hydrus.Network.563.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v563/Hydrus.Network.563.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v563/Hydrus.Network.563.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v563/Hydrus.Network.563.-.Linux.-.Executable.tar.zst

I had a good week. There's a mix of small fixes and improvements.

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

macOS

A user has improved the macOS release in many ways, mostly in brushing up the App to normal macOS standards. The menubar should now plug into native global bar, with some standardised command labels. The program icon is better, some colours should be improved, dialog menus are no longer a crazy hack by default, and the system tray icon is turned on. In a side thing, I also added Cmd+W to close pretty much any dialog or non-main-gui window in macOS, just like hitting Escape.

I think we can expect more work here, so let us know how you get on!

all misc

In more shortcut news, I've added Alt+Home/End/Left/Right to the 'thumbnails' defaults to perform the new thumbnail rearranging. Existing users will also get these! (assuming it doesn't conflict with something you already have set)

Also, the shortcut system now, by default, converts the 'numpad' variants of non-number key presses (think 'numpad Home' or 'numpad Return') into the non-numpad 'normal' ones. You now only need to map 'Left' or 'Delete' once when setting a shortcut, and, no matter how crazy your keyboard's internal mapping is, it should just work. If you do need to differentiate between the numpad and normal variants of these keys, you can turn this new behaviour off under options->shortcuts.

The menu on a 'file log' button now lets you delete all the remaining 'unknown' items or set them all to skipped.

I fixed another damn problem with copy/pasting timestamps into the manage timestamps dialog. When you paste a timestamp, it should 'stick' better now!

If you have had problems with mpv sometimes going silent on 'every other video' or had your windows being rescued from 'off screen' even though they were supposed to appear just on some monitor, check the changelog for some special new BUGFIX options.

next week

I want to put some work into system predicates, specifically startng with 'system:duration'. The aim is to eventually get rid of all the +/-15% '~=' stuff and replace it with actual customisable values, along with better behind the scenes storage of that data. We'll see how it goes!



https://youtube.com/watch?v=XnwHtzBf-c8
(go to 4:44:00 for a wild fight)
windows
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v562/Hydrus.Network.562.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v562/Hydrus.Network.562.-.Windows.-.Installer.exe
macOS
app: https://github.com/hydrusnetwork/hydrus/releases/download/v562/Hydrus.Network.562.-.macOS.-.App.dmg
linux
tar.zst: https://github.com/hydrusnetwork/hydrus/releases/download/v562/Hydrus.Network.562.-.Linux.-.Executable.tar.zst

I had a tepid week, but there's some decent fixes and quality of life improvements.

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

all misc this week

I fixed a stupid typo error in the manage times dialog when you go into a single time and try to copy/paste the timestamp. The buttons also add millisecond data now.

Fingers crossed, drag and drops of thumbnails and page tabs will feel snappier this week.

You might see some heavy 'analyze' database maintenance coming down the pipe. Let me know if it proves annoying, or if you even notice it at all--my hope is to iron out some super slow PTR-based tag updates that hit some users, but we'll see how it goes.

If you are an AUR user or otherwise updated to a very new Qt version (6.6.1) and suddenly the column widths of multi-column lists all went ~100px wide, I think I've fixed it! If you were affected by this, I can't recover your old settings, but recall that you can right-click any list header to reset the widths to the default.

next week

I was short on work time this week, so I'll try to hack away at github bug reports again.



thumbnail of 46643064 Laxim - Reference.png.txt
thumbnail of 46643064 Laxim - Reference.png.txt
46643064... txt
(821 B, 0x0)
In future I hope to have an xml/html parser for sidecars, but I can't promise when it will be ready. So, if you have time, I think save these for later. Otherwise, parse them yourself and make JSON/txt files, or just run the download again if possible.




Post(s) action:


Moderation Help
Scope:
Duration: Days

Ban Type:


0 replies | 0 file
New Thread
Max 20 files0 B total
Refresh