/hydrus/ - Hydrus Network

a few bugs i've noticed since 373:

1. in the media viewer, if you click on a link on the top-right of the viewer, it will always bypass what browser you've set in the hydrus options and it will use the default browser on your system. (this doesn't happen when launching the original url from either a shortcut or the right-click thumbnail menu, though.)
2. on windows, if you open up the tag editor from the media viewer, you can minimize and maximize the tag editor that pops up. not sure if that's intentional.
3. as of the latest version (v376), if you have the ui style set to 'fusion', closing the options menu (when hitting either apply or cancel, doesn't matter) will make the client lag out for a second or two. i'm assuming this is because of the new theming options you've added.
4. if you have the ui style set to 'fusion', sometimes if you right click on a tag in the selection tags pane, it will automatically select the first option in that menu without asking if you let go of the mouse button too early
5. ever since 373, scrolling through thumbnails has been SLIGHTLY slower than on the wx builds. not sure if this is fixable but i thought i'd point it out
6. the 'collapse all notifications' arrow button is wider than it was in the wx builds. again, not sure if intentional

i think there are a couple more i forgot to put here but overall i am happy with the recent versions so far. if you can fix up these issues that would be really good. thanks dev!

I'm using Hydrus 376 on Fedora Workstation.

When using Hydrus in Wayland, it will immediately crash any time that it's supposed to open a file-select window. 
This doesn't happen on Xorg. On Xorg, It just opens the window like it should.

 >>/416/
BTW this bug has been happening since at least V373, although before that version, Hydrus wouldn't work at all on Fedora and I had to use the Windows version through Wine, so I don't know when this became an issue

 >>/415/
Thank you for these reports.

1) I just fixed it now, should be good for 377. Let me know if you still have trouble.
2) This is actually intentional. Manage tags is a 'modal' dialog (stops interaction with the program when open, has apply/cancel) when launched from thumbs, but just a normal window (also sends changes immediately to media, has no cancel) when launched from media viewer.
3) Thanks, I have heard this from someone else as well. I think it is a fusion/Fusion capitalisation issue or something.
4) Ah, I heard this from someone else as well, I didn't know it was with fusion. I'll check it.
5) Thanks. I have noticed them being faster, so that is interesting. I don't have a profile mode to check the drawing speed here, but I will think about how to add one so this sort of thing can be tested better.
6) This is probably a font issue. I think that character is unicode text ▼, rather than an icon. If it looks ok to you, I'm good, but if it screws things up, let me know. Some of those odd characters are sometimes positioning a few pixels to the right and down in Qt.

 >>/416/
 >>/417/
Thank you for this report. I am sorry for the trouble. Are you using my Linux release in Fedora, or running from source? Opening something like a file dialog typically asks the OS to open its own file selector, and I wonder if there is a mismatch between my bundled Ubuntu's .so files and your Linux.

I recently saw that I can apply a flag to draw those dialogs natively to Qt, rather than calling the OS. I'll see if I can add that as a debug option, either this week or next, so we can test this out more.

 >>/420/
I'm using your release. I'm not knowledgeable enough to run from source, else I'd try that before reporting this to see if that changed anything.

Regardless I'm just glad I can use Hydrus on Linux now, even if I have to use the somewhat depreciated Xorg for the time being instead of Wayland. That native Qt dialog option sounds like a good potential workaround though.

I'm using Ubuntu 18.04.

So I tried upgrading hydrus and it doesn't start.
I was on 381 and first I tried upgrading to 389, then 383, neither of which worked.
I successfully upgraded to 382, then tried 383 again from there, but that also didn't work

Terminal error message, same each time:


./client

2020/03/30 02:41:04: hydrus client started
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

Aborted


I guess I'm stuck on 382 for now. Hooray for btrfs snapshots.

 >>/589/
Thank you for this report. After a bit of searching, it seems like your Ubuntu is having trouble finding some Qt-related library. I think this stack answer is the correct next step to find more information:

https://askubuntu.com/a/1054691

So open a terminal and do "export QT_DEBUG_PLUGINS=1" and then try to open the new client again. Hopefully it will talk more about exactly which library or .so it is having trouble with here. Looks like an apt-get reinstall of that is a common and safe solution.

As a side thing, in a recent version of the client, I changed some PATH stuff to make it easier for hydrus to pull the correct .so files from its base directory. The errors that lead me to do that were different to what you are getting, but if this problem happens to be related to that, does a very new version of the client boot? You can just try an empty extract of 390 on your desktop. If that works, then I recommend you just jump up to a new version and skip the ~382 ones that are giving you trouble.

Let me know what you find!

 >>/590/
> try an empty extract
Derp, I should have thought of that.
I tried fresh extracts of 383, 386, 389, and 390, and each one ran.

 >>/590/
Here's the terminal message from "export QT_DEBUG_PLUGINS=1" on 383 extracted over my 382 install.
(Continued due to char limit)

 >>/597/
./client
2020/03/30 18:35:30: hydrus client started
QFactoryLoader::QFactoryLoader() checking directory path "/home/anon/hydrus-test-383/PySide2/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqeglfs.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqeglfs.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "eglfs"
        ]
    },
    "archreq": 0,
    "className": "QEglFSIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("eglfs")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqlinuxfb.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqlinuxfb.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "linuxfb"
        ]
    },
    "archreq": 0,
    "className": "QLinuxFbIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("linuxfb")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqminimal.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqminimal.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "minimal"
        ]
    },
    "archreq": 0,
    "className": "QMinimalIntegrationPlugin",
    "debug": false,
    "version": 331008
}
(Continued)

 >>/598/
Got keys from plugin meta data ("minimal")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqminimalegl.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqminimalegl.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "minimalegl"
        ]
    },
    "archreq": 0,
    "className": "QMinimalEglIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("minimalegl")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqoffscreen.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqoffscreen.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "offscreen"
        ]
    },
    "archreq": 0,
    "className": "QOffscreenIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("offscreen")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqvnc.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqvnc.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "vnc"
        ]
    },
    "archreq": 0,
    "className": "QVncIntegrationPlugin",
    "debug": false,
    "version": 331008
}
(Continued)

 >>/599/
Got keys from plugin meta data ("vnc")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-egl.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-egl.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "wayland-egl"
        ]
    },
    "archreq": 0,
    "className": "QWaylandEglPlatformIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("wayland-egl")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-generic.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-generic.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "wayland"
        ]
    },
    "archreq": 0,
    "className": "QWaylandIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("wayland")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-xcomposite-egl.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-xcomposite-egl.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "wayland-xcomposite-egl"
        ]
    },
    "archreq": 0,
    "className": "QWaylandXCompositeEglPlatformIntegrationPlugin",
    "debug": false,
    "version": 331008
}
(Continued)

 >>/600/
Got keys from plugin meta data ("wayland-xcomposite-egl")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-xcomposite-glx.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwayland-xcomposite-glx.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "wayland-xcomposite-glx"
        ]
    },
    "archreq": 0,
    "className": "QWaylandXCompositeGlxPlatformIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("wayland-xcomposite-glx")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwebgl.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqwebgl.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "webgl"
        ]
    },
    "archreq": 0,
    "className": "QWebGLIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("webgl")
QFactoryLoader::QFactoryLoader() looking at "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqxcb.so"
Found metadata in lib /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqxcb.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "xcb"
        ]
    },
    "archreq": 0,
    "className": "QXcbIntegrationPlugin",
    "debug": false,
    "version": 331008
}


Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/home/anon/hydrus-test-383/platforms" ...
Cannot load library /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqxcb.so: (/home/anon/hydrus-test-383/libgcrypt.so.20: symbol gpgrt_get_syscall_clamp version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference)
QLibraryPrivate::loadPlugin failed on "/home/anon/hydrus-test-383/PySide2/plugins/platforms/libqxcb.so" : "Cannot load library /home/anon/hydrus-test-383/PySide2/plugins/platforms/libqxcb.so: (/home/anon/hydrus-test-383/libgcrypt.so.20: symbol gpgrt_get_syscall_clamp version GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference)"
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

Aborted

 >>/590/
 >>/597/
 >>/598/
 >>/599/
 >>/600/
 >>/601/
390 over my 382 also didn't start.

386, 389, and 390 over my 382 with "export QT_DEBUG_PLUGINS=1" gave me an exactly identical message as above, other than the directory name and timestamps obviously.

 >>/590/
 >>/601/

So it can't load the files

PySide2/plugins/platforms/libqxcb.so
libgcrypt.so.20

And a symbol is not defined in
libgpg-error.so.0

Which I checked, all three do exist.


Additionally, I ran "sudo apt remove xcb", ran the client, ran "sudo apt install xcb", and ran the client again.
It didn't give me any different results either time, compared to above.

Longcatbeofgreatlength jpg
(178.55 KB, 662x548)

 >>/590/
 >>/597/
 >>/598/
 >>/599/
 >>/600/
 >>/601/
 >>/602/
 >>/603/

Pastebin should be more readable
https://pastebin.com/ViAypfDe

ikazuchi inazuma... gif
(1.61 MB, 498x278)

 >>/590/
 >>/604/
Got it updated and working now!

I deleted everything except the db folder, and extracted 391 over it.

 >>/613/
Damn, I am sorry I got back to you late here. I am glad you got sorted. I will make sure I highlight in my help somewhere about doing a 'clean install' as you did, as this has fixed several dll/so related issues.

Let me know if you have any more trouble here!

R34.paheal automatically redirects search queries with only one result, which breaks the parser even though the end result is recognized by the parser. 
https://rule34.paheal.net/post/list/md5%3A942d23d3583746387fb27e38daecb3c9/1 doesn't work, but if you access it in your browser you get redirected to https://rule34.paheal.net/post/view/2833219 which works in the url downloader. 
I don't think there's any way to fix this by messing around with the parsers.

 >>/851/
Thank you for this report. I had a similar report for something else recently. I will have to update the network engine to catch redirects when it points to a different URL Class type and handle it differently.

easy-import... png
(3.54 KB, 512x113)

I fixed the old bleachbooru parser for the new URL but the file pages always fail due to a connection refused error.
The gallery downloader properly downloads and parses the gallery. The parser test properly downloads and parses the file and gallery page. Downloading a direct image (e.g. bleachbooru.org/data/sample/59/83/59839fad73eca750f5c43dabdca1efca.jpg instead of bleachbooru.org/post/show/41663) works. 
But it always fails when downloading the post pages through the URL and gallery downloader. 
As it can properly download the gallery page, the image, and the tags separately I'm inclined to think it's a bug in hydrus.

easy-import... png
(3.58 KB, 512x113)

 >>/885/
Turns out I'm stupid. 
I got the parser working but I probably closed it without saving so it was still using the old URL, here's the fixed version.

I just noticed that all of a sudden Hydrus isn't pulling any tags from gelbooru. As in, it was working earlier today, and now it is not getting anything other than the "rating." Same thing for both individual url downloads and gallery downloads. Is there something known that could cause this?

 >>/901/
> Hydrus isn't pulling any tags from gelbooru

This happened to me today as well, on both versions 424 and 425.

 >>/901/
 >>/904/
Can confirm on both versions, 424, 425. Other sites work just fine.

Endchan is becoming the primary /hydrus/ board, and I am deleting the 8kun board within a week. Here is the archive of the latest 8kun Bug Reports thread:

https://archive.is/cq5Tc

Archive.is missed the last post I made in the 8kun bug reports thread, I am copying it here:

 >>/15117/
 >>/15118/

I will be folding this into 426 btw.

 >>/15125/

Thank you for this report. I am sorry for the continuing trouble. If searches are slow when you are searching a page of results, but fast when you search an empty page (or one with 'searching immediately' off, which then searches the database, rather than the tags for the files in front of you), then the routine that is generating search results from thumbnails is slow.

Some more feedback would be very helpful. Please run 'db profile mode' and do some slow autocomplete searches with files in front of you, and then pastebin or email me that profile log. It is the 'media_predicates' routine that is running slow for you.

The  >>/15000/ query on client.caches.db would be helpful. Let's see what SQLite wants to be doing here.

 >>/901/
 >>/904/
 >>/905/
They changed their markup. Sorry for the trouble. A user has helpfully sent me an updated parser, which I will roll into 426.

I went into review services like 2 days ago, and at the bottom under repository sync, I clicked "process now".
It took like 2 days of going through.

What does this do? Because I just ended up with an error stating disk space was low so it stopped.

Now, my disk space is kinda low on that drive, however I am curious.. how much did Hydrus fill up? My hydrus folder shows it's like 90gb, but if I go check how boned am I, it shows that I only have 50gb worth of files.

Did Hydrus use 40gb of space for a repo???

 >>/915/
worth noting, I had installed hydrus, I was completely up to date about a year ago. I stopped using it, and came back. Under repository sync it said I had like 7k/9.8k downloaded.

When I had clicked "process now" it showed in the notifications it was going through like 700k lines or tags or something? Idk.

I'm a little confused what it was doing tbh.

But either way, I don't see why it would grow that much. I am currently at 9378/9837 downloaded, and 8125/9837 processed it shows.
So I don't understand why my database would've grown more than maybe 10gb if even that. 

The docs aren't very helpful unless I missed something. I'm very confused on what the process now does, what download now does.

Do I just have to vacuum my db?

 >>/914/
Does Hydrus detect and update existing parsers with updates, or does one have to do something special (like, say, deleting the older version) beforehand?

 >>/921/
When I tried adding the new parsers, it just made a another like 

> gelbooru 0.2.5 file page parser
> gelbooru 0.2.5 file page parser (1)
I just ended up deleting the first one and renaming the new one like the original. I would definitely like to see an notice or something that shows user made/added scripts.  Its real easy to forget what you've done in the parsers, headers, cookies, or any scripts. Like a column that says "user made" or something.

 >>/912/
The plan to move to Endchan only has changed!

Sorry for the sudden change, this all came together this week!

Codexx on 8chan.moe has kindly offered to host me on /t/ over there. As I have never been a comfortable BO, this is a much better solution for me as the primary place to talk Anon about hydrus.

I will be maintaining a Hydrus Network General, the first instance is here: https://8chan.moe/t/res/2219.html

The links in the release tomorrow will reflect this. Endchan will remain as a bunker.

 >>/915/
 >>/916/
The PTR is very large these days. It is just over a billion tag mappings. Due to the way hydrus repos work, your database ends up building a cache of all that data. Although the compressed update files you download only total I think about 5 or 6GB, once all that data is unpacked and indexed and 'processed', it is about 42GB or so of db data to store, in the client.*.db files in your install_dir/db directory.

I now only recommend the PTR for users on SSD who have the space for it. You also need some spare space, I recommend at least 10GB and preferably a more comfortable margin, for temporary operations when processing and other big maintenance occurs.

As you ran out of space, please pause repo processing under the services menu. If and when you can figure out some more SSD space for the db, you might like to continue processing. If you want to clear all that space, you can delete the PTR from the services->manage services menu and then run a vacuum under database->maintenance->vacuum.

As the PTR is ever-growing, I am exploring different options with the guys who now run it to break it up into topics or offer options like 'sync with the PTR, but only get character/series/creator tags' kind of processing filters.

 >>/921/
 >>/926/
This whole process fucking sucks, I hate it and I am sorry.

When I roll an updated parser into a release, it should update you automatically fairly nicely and the name stays the same.

The (1) business is an artifact of the older system. The next version of the network engine will have downloader versioning and hopefully an external repo to look at, a bit like a vidya Mod Manager, and you'll be able to get updates as soon as an author publishes them.

Gelbooru shows up as "unknown subject" under thread watcher. It would be nice if it could say something like "Gelbooru - tags".

Makes it really hard to identify which is which before selecting.

 >>/959/
Can confirm this issue
Titles show up fine under gallery downloader when just typing in tags

Also it would be nice to have an option to send gallery downloads to be watched for new posts after downloading instead of manually needing to go grab the link

 >>/939/
People have been using compact.exe in Windows 10 to reduce install sizes of games with little or no performance difference, using GUIs like CompactGUI.

Out of curiosity I tried it on my 50GB database and it halved the size. Not sure how much that would affect performance in Hydrus. Do you have any idea? It might be helpful for people with limited space.

Hey, I am sorry for delay, just catching up.

 >>/959/
 >>/962/
Ah, there has been a misunderstanding. I never knew you could paste a booru gallery URL into the thread watcher and have it do something.

The thread watcher is meant for things like endchan or 4chan. It repeatedly checks the same thread url for new image posts. It seems my downloader code is accepting single gallery pages into the watcher, but then is not sure what to do with them after that page is hit.

Please use the 'gallery' downloader for gallery-like boorus. That lets you input text like 'skirt' or 'samus_aran' and it will do a multi-page search with a nice 'query' saved based on what you typed in.

If you would like to 'watch' a gallery download, please check out the 'subscriptions' system, which does exactly what you want:

https://hydrusnetwork.github.io/hydrus/help/getting_started_subscriptions.html

 >>/965/
Thanks. A user was telling me a week or two ago that NTFS compression, which you can do straight from windows explorer, is good as well--about 40-50% savings on the client*.db files. This is pretty interesting, and I would like to gather more data on performance impact. Seems like if you have a killer SSD and CPU it is doable though.

I don't know enough about compression tech to know why that can update quickly, but I guess there is a constantly maintained compression 'dictionary' for that file in the NTFS filesystem so you can update a single block in the file without having to de a bunch of recompute based on other blocks in the file.

My biggest tables in the database are basically two copies of the same data, but 'forwards' and 'backwards', which I think explains why compression is working so well. I have to have the data splayed out like that for SQLite to work fast, but if it seems modern CPUs can de/compress that on the fly, it would be pretty neat.

I just updated my client, only was behind like 3 versions.
I get an error stating v426 subtag repopulation routine failed, the dev would be interested in the log.

What logs do I provide? And does this mean there is something seriously wrong?
Windows 10.

Besides that, it seems to have updated to 431 no issues, although I haven't looked around much.

Screenshot 2021-03-08... png
(6.87 KB, 306x126)

Why the 1.3MB ≈ 1.3MB? I'd like to know which is bigger in these cases so i can save a few bytes.

 >>/995/
> If you would like to 'watch' a gallery download, please check out the 'subscriptions' system
ah this makes more sense, however maybe a simple button that can enable a search done through gallery download, to then be added to subscriptions would be nice?
Basically if you do a gallery download, offer a button "add to subscriptions".

> 4chan archive error
Also worth noting, 4chan's built in archives don't seem to want to download. They seem to be unrecognized and just error.
By archives, I mean pages that 4chan recently deleted that are listed for example here: https://boards.4channel.org/g/archive

> third party archives
I haven't tested third party archive sites, however I would assume they don't work either. It would be nice to support those if that is true.

thanks devanon

When using simple downloader to download this
https://danbooru.donmai.us/posts/3393214?q=parent%3A3393160 (NSFW)
It only downloads one of the files, not the parents.

It detects 4 it says, ignores 3.
I tried to manually feed it the direct links to the other images, and it just ignores them as well?

Capture PNG
(33.05 KB, 675x453)

Windows Defender detected the Hyrdus client as a trojan and uninstalled it. I know it's probably a false positive, but I wanted to make you aware of it. Unfortunately, I can't remember the version I was on, but I think it was 431 or 432. I tried installing 433 just now and the same thing happened.

hey im trying to use the url downloader and it wont find parse this url e621.net/posts/2662369

where do I go or what do I do?  who knows how many downloads were affected

same with this e621 posts/2659888

Not sure if this is a bug or if I'm missing something, but I screwed up and ran out of space on the disk I keep my DB on. It's not the first time this has happened, but this time it seems to have broken Hydrus somewhat.

It takes a long time to start now, and then it works slowly but normally for a while before it decides it's out of space again, at which point I can't make any changes, like deleting files to free up space.

I've used the moments where it does work to delete some of the bigger files to free up 25 GB. This is 5% of the entire disk, and although I think it's made it a little better, meaning it takes a bit longer for it to think it's run out of space, it hasn't actually fixed the problem.

Is there a way to fix this other than replacing the database file entirely and reimporting the nearly 500 GB worth of client files?

Capture PNG
(9.15 KB, 574x116)

I'm following what this message is telling me to do. I don't know how or when this popped up but I just noticed it when I looked at Hyrdus today. I'm on v434, Win10 19042.

I'd like to start this post off by saying that I'm using the AUR version of Hydrus and I know there isn't any real support for Linux builds in general, but I'm still posting this here in case someone else had the same problem, or possibly even knows what fucked up and how to fix it. Alright -

Dark mode seemed to just stop working for me one day. It looks exactly like the default white color scheme except the backdrop for image preview areas is the dark gray color that dark mode typically uses. I checked the "colours" in options and everything seems to be fine too (although I don't think you can change the color of the hydrus window itself through there anyway). This just kind of suddenly started happening after booting up Hydrus one day. It wasn't after updating or anything like that either.