/hydrus/ - Hydrus Network

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

Boards | Catalog | Bottom

Check to confirm you're not a robot
Drawing x size canvas

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Qt Release Tomorrow! Anonymous Board owner 11/13/2019 (Wed) 08:11:44 Id: 2aeee8 [Preview] No. 269 [Reply] [Last 50 Posts]
I had a great and very busy four weeks. I appreciate everyone's patience.

The hydrus client is now switched over to a more stable and feature-rich Ui library, Qt. This is a big and important change behind the scenes, but the client looks and works essentially the same as before, though smoother and less flickery. The update process should be as normal--no special instructions. I also folded in a little normal work, including an important fix to the file maintenance system and some quality of life gui improvements.

The release is likely to be late tomorrow, as I want to do some more testing on my own system and with advanced users. I have a working macOS build, but it has some sizing/layout problems still to fix, so if I cannot nail them down, the macOS release will be delayed a week for 374.

wx->Qt Status Update 3 Anonymous Board owner 11/06/2019 (Wed) 09:58:27 Id: 850c73 [Preview] No. 263 [Reply] [Last 50 Posts]
Things are going well with the update. I am coming to the end of my ‘must do before a release’ todo list. I feel good about having a decent release ready for the 13th, and hopefully with a couple of new bells and whistles thrown in.

I would still like to do a test release for advanced users, mostly to test that my builds will at least boot on various systems and there are no very unpleasant surprises. I had thought to do this later today, the 6th, but there are still some important things I want to do, and I do not want to rush it out just for the sake of it. I will now aim for Saturday the 9th.

Anonymous 11/06/2019 (Wed) 11:43:03 Id: e7d0d5 [Preview] No.264 del

Version 372 Anonymous Board owner 10/16/2019 (Wed) 21:33:49 Id: 4fd51a [Preview] No. 221 [Reply] [Last 50 Posts]

Message too long. Click here to view full text.

13 posts and 12 images omitted.

Anonymous Board owner 10/26/2019 (Sat) 20:52:55 Id: 4fd51a [Preview] No.242 del
Thank you, I replied to your email.

Anonymous 11/03/2019 (Sun) 18:39:19 Id: fede9d [Preview] No.258 del
A-are you still developing this software?
I just wanted to pop in to say that it is awesome!
Damn, I miss 8chan...

Anonymous 11/03/2019 (Sun) 22:03:10 Id: 207983 [Preview] No.259 del
software is still going, right now the ui is being transplanted into a different engine that should let it do more, one of the bigger things, it would allow the embedding of mpv and potentially bring audio on top of playback improvements, and if the dev disappears, im told there are people who would take over development. not sure how true that is, but it's a nice safety net incase something happens to hdev. on that note, the next release is coming next wednesday as a preview and the wednesday after for the next one for everyone, but I haven't been keeping up to much on what the current plan is.

Anonymous Board owner 11/04/2019 (Mon) 02:16:44 Id: 8185d1 [Preview] No.260 del
Yep, I am still here. >>259 is correct.

373 will be a special release that is taking more time. See the 'next week' section of the release post above. Once that is out, I'm back to normal weekly schedule.

I do short updates on my twitter here if you are interested in more frequent news: https://twitter.com/hydrusnetwork

It is mostly 'good day today chipping away at this big todo in front of me' at the moment. With luck and a couple of late nights, I should have a test release for advanced users out on the 6th, and a proper, bug-freer one (which if you are more new to the program, I recommend for you) out on the 13th.

8kun is trying to do their proper launch now. I expect the release on the 6th will be here, but if 8kun is stable and has a decent userbase again and /hydrus/ is migrated all correct by the 13th, I expect to move back.

Anonymous 11/05/2019 (Tue) 18:26:06 Id: f8be6f [Preview] No.261 del
Thanks for the clarifications guys, and you, Mr. Dev, are an awesome dev for actually taking time to respond to such questions, even if they were a bit stupid, sorry.
Have a great day!

(1.39 MB 1566x1136 working exe.png)
wx->Qt Status Update 1 Anonymous Board owner 10/23/2019 (Wed) 02:55:26 Id: c263d1 [Preview] No. 232 [Reply] [Last 50 Posts]
I had a good week. I received the Qt code from the user who put the conversion work in and have familiarised myself with the very basic differences between wx and Qt. The client boots and runs well. I also managed to create a working build for Windows today, so there do not seem to be any huge technical hurdles to getting this done.

There are still things for me to learn, bugs to deal with, and miscellaneous work (fixing layout issues and so on) until the release will be ready. I feel very good about things and believe I am on schedule to put out 373 on the 13th of November. I will put out a preview build for advanced users to give feedback for on the 6th.

Anonymous 10/25/2019 (Fri) 15:39:27 Id: 1e4380 [Preview] No.238 del
I'm kinda curious about the reason for wx>Qt migration, what is it? Better crass-platform support, documentation or such?

Anonymous Board owner 10/26/2019 (Sat) 18:45:50 Id: c263d1 [Preview] No.241 del
It is a bunch of different things really. As you say, it has wider support on non-Windows, but it is also more internally customisable, so 373 should have support for complete program theming and a proper night mode. It uses CSS files, funnily enough.

It has a larger and more active dev team, more support for modern tech like swipe actions and high DPI displays, better code, more plugin support. With luck, I'll also be able to launch an embeddable mpv window in the media viewer for 373, which will mean nice video and audio support in one go.

Now I have gotten into it, I think I personally like Qt a bit more than wx. I am feeling good about working with it more in future.

The user who wrote the conversion is enthusiastic about Qt and has been talking to me about the idea of converting for more than a year, I think. I generally agreed with the concept of moving over, but the idea of changing all the code in one go was always too much work. He suggested maybe trying to write an auto-code-converter if I was ok with it (which I was), worked on it for ages, and here we are.

Anonymous 10/26/2019 (Sat) 23:17:03 Id: d8b935 [Preview] No.243 del
speaking of qt, another qt program called ripcord actually uses its own custom qstyle that has light and dark modes. i'll link it here so you can consider putting it into hydrus in the future: https://github.com/randrew/phantomstyle

Anonymous Board owner 10/30/2019 (Wed) 00:07:45 Id: 045b91 [Preview] No.250 del
Thanks mate, I'll check this out properly. My initial work here may be more basic, but as I learn Qt's systems more, I am all for more user theming in the program.

Version 371 Anonymous Board owner 10/09/2019 (Wed) 22:27:01 Id: 83b1de [Preview] No. 194 [Reply] [Last 50 Posts]
https://youtube.com/watch?v=aZClzeSIVNA [Embed]
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v371/Hydrus.Network.371.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v371/Hydrus.Network.371.-.Windows.-.Installer.exe
os x
app: https://github.com/hydrusnetwork/hydrus/releases/download/v371/Hydrus.Network.371.-.OS.X.-.App.dmg
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v371/Hydrus.Network.371.-.Linux.-.Executable.tar.gz
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v371.tar.gz

I had a good week. There are several fixes, and I have added 'favourites' management for tag filters.

favourite tag filters

The Tag Filter is the newish whitelist/blacklist panel that manages which tags will be parsed, blacklisted, migrated, or, more recently, hidden on the new tag display system. It is being used in more and more places, so I have added the ability to save and load certain filters for quicker re-access.

Message too long. Click here to view full text.

6 posts omitted.

Anonymous Board owner 10/12/2019 (Sat) 21:32:21 Id: 83b1de [Preview] No.214 del
Probably not. The db does not work well if its four files are out of sync, and I would not recommend any backup scheme that does not keep them together. I can't easily pull the tag repo 'table' out of the db, as it is 'processed' and closely coupled with everything else.

Can you talk a bit more about your backup/update routine? I am not sure I completely understand, and perhaps we can make that more efficient.

Anonymous Board owner 10/12/2019 (Sat) 21:36:28 Id: 83b1de [Preview] No.215 del
Damn, thank you for putting the effort in here. I will look into this and update the code as you have done. I don't send anything on stdin to ffmpeg, but I guess your OS wants that link.

Anonymous 10/14/2019 (Mon) 06:30:37 Id: 2682d0 [Preview] No.216 del
more or less goes like this, when i update the program, move the old database folder to a hdd as a mirror and install the new version, that way im never really going backwards to much.

however what i'm thinking is, if one of those files are dedicated specifically to the repository, and if shit hit the fan could be redownloaded, the need to have a running backup of that is far lesser, so instead of leaving it in the db, I symbolically link it to the db, this should have the program see the file and use it like it normally would, but on backup it would not transfer the file over, just the symbolic link, meaning that 18(nearly 19)gb can be cut from the backup cutting what gets backed up from 42gb down to 25

if client.mappings is just repository and not keeping a solid backup of this would be detrimental, i think symbolically linking it would be a good way to save on the versioned backup

Anonymous 10/14/2019 (Mon) 06:32:27 Id: 2682d0 [Preview] No.217 del
oh, I should point out, the backup I have here is the most recent one made when I updated, but due to having shit to do, I didn't go with 370 and went to 371

Anonymous Board owner 10/19/2019 (Sat) 17:24:14 Id: d63590 [Preview] No.228 del
Thank you for the update. If you aren't already, I recommend a program like FreeFileSync, which will work much faster than a manual folder copy for backing up. It will let you mirror to the same folder and only update files with new modified dates, so you aren't always re-copying media files.

You can try doing some symlink stuff, but I think SQLite may have a problem with it. The automatic recovery options for client.mappings.db are not excellent yet (for if, say, it was corrupted/lost, and you needed the client to auto-generate a fresh empty one), so I recommend not playing around with this too much for now.

Anonymous Board owner 10/15/2019 (Tue) 22:16:05 Id: 00d6f2 [Preview] No. 219 [Reply] [Last 50 Posts]
I had an ok week. I mostly fixed bugs to make a nice 'clean' final release in wx.

The release should be as normal tomorrow. It will be the last release for about four weeks, as the next job will be finalising an large and long-planned wx->Qt (UI library) conversion.

Anonymous 10/16/2019 (Wed) 18:53:00 Id: dcd643 [Preview] No.220 del
So the last release would be October 16th...
And the first Qt release would be November 13th...
Hope we can celebrate 8th BDay on December 14th
(which is about 8 weeks from today)

Version 370 Anonymous Board owner 10/03/2019 (Thu) 00:10:55 Id: 48e809 [Preview] No. 148 [Reply] [Last 50 Posts]
https://youtube.com/watch?v=h27wMuv_--s [Embed]
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v370/Hydrus.Network.370.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v370/Hydrus.Network.370.-.Windows.-.Installer.exe
os x
app: https://github.com/hydrusnetwork/hydrus/releases/download/v370/Hydrus.Network.370.-.OS.X.-.App.dmg
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v370/Hydrus.Network.370.-.Linux.-.Executable.tar.gz
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v370.tar.gz

I had a great week. There's a big improvement to tag display management and a bunch of smaller stuff.

tag display

Part of this ongoing tag overhaul work I am doing is to catch up some ancient systems that aren't able to deal with the size of the dbs we have now. The old 'tag censorship' is probably the biggest example of this. I have rewritten this to work in a more sensible way using newer objects.

Message too long. Click here to view full text.

17 posts and 2 images omitted.

Anonymous 10/08/2019 (Tue) 11:56:05 Id: 9d26bb [Preview] No.184 del
Log sent!
Tell me if something is missing.
Sorry for late.
I was away from my PC when posting previous one.

Anonymous 10/09/2019 (Wed) 06:49:35 Id: c312d6 [Preview] No.191 del
Ok going though more fucking gifs and webm's jesus I hate doing this but it needs to get done.

so, I know that hotkeys are at least on the table/in the works, this will for me make this complaint moot, but would it be possible to increase the size of the play bar? I want to scrub though things to get to the point, but due to it being 20 pixels high, I end up missing it quite a bit after a few thousand files have been parsed. would it be possible to make that section user definable big? if not, an option to have it be 40-60 pixels big? at least for me this would make misclicking a bit harder.

Anonymous Board owner 10/10/2019 (Thu) 00:14:53 Id: c05b20 [Preview] No.201 del
Thanks m8, I will read through those emails and respond there properly on Saturday, when I am back working at my dev machine. I would like to put some optimisation into 372, so I appreciate having your data.

Anonymous Board owner 10/10/2019 (Thu) 00:21:54 Id: c05b20 [Preview] No.202 del
Thank you for this report. Is it possible that when you first tried it, your database was locked? When the thumbnail right-click generates its menu, it needs to do a real fast db hit to fetch similar files metadata. If the db is locked, it skips that to ensure the menu gets made fast and I think should replace the similar files stuff with a label like 'db is locked, could not fetch info'. I have a longer-term plan to load duplicate file info with the initial media load and no longer need this menu db hit, but until then, that's the compromise. Since your client has some lag, could it be in part db-based?

I will have a look to make sure the menu properly shows a nice message when the db is locked, and to make sure the 'search for similar' still appears even if so. It is possible it got hidden somehow when I recently reorganised things.

If you are confident the db was not locked, or it seems to be hidden anyway, is there any chance you could take a screenshot or just list what your manage menu does look like? Maybe one menu entry is stomping on the file relationships menu out of order or something.

Anonymous Board owner 10/10/2019 (Thu) 00:24:08 Id: c05b20 [Preview] No.203 del
Sure, thank you for this suggestion. That is a good idea.

Relatedly, when we move to Qt, which should be done about five weeks from now, it looks like the client will be able to offer the option of a full embedded MPV window instead of my native renderer. This will handle video a hell of a lot better. I'll be keen to see if I can hook hydrus shortcuts into this embedded window as well.

Anonymous Board owner 10/09/2019 (Wed) 00:44:10 Id: bd0551 [Preview] No. 190 [Reply] [Last 50 Posts]
I had a good week. I mostly fixed things and cleaned code, and I added 'favourite' tag filters to make it easier to manage and reload common filters.

The release should be as normal tomorrow.

Version 369 Anonymous Board owner 09/25/2019 (Wed) 22:08:17 Id: 6988a8 [Preview] No. 115 [Reply] [Last 50 Posts]
https://youtube.com/watch?v=ACAvBBMb6BM [Embed]
zip: https://github.com/hydrusnetwork/hydrus/releases/download/v369/Hydrus.Network.369.-.Windows.-.Extract.only.zip
exe: https://github.com/hydrusnetwork/hydrus/releases/download/v369/Hydrus.Network.369.-.Windows.-.Installer.exe
os x
app: https://github.com/hydrusnetwork/hydrus/releases/download/v369/Hydrus.Network.369.-.OS.X.-.App.dmg
tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v369/Hydrus.Network.369.-.Linux.-.Executable.tar.gz
tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v369.tar.gz

I had a good week. The file maintenance system works better, and files now know their 'modified' dates.

file maintenance

The new file maintenance system now works smarter and more productively. Previously, it did rare bursts of hard work in idle time, and now it does small amounts of work all the time. You do not have to do anything--it will now keep up with its behind-the-scenes queues more quickly and quietly, hopefully without giving you any hassle. The only significant difference is file maintenance no longer occurs on shutdown. If you are not interested in any details, you can skip the following completely.

Message too long. Click here to view full text.

20 posts and 4 images omitted.

Anonymous 10/02/2019 (Wed) 20:23:25 Id: b1e302 [Preview] No.147 del
For the most part, the issue I had only happens after I have 50 days of uptime so I lump it into bullshit just building up till windows cant take it, and its not a blue screen, everything just freezes up and stops responding at all when this happens. the only common link between the two was hydrus being open and doing the repository so I figured mentioning it was better then not.

as for drivers... my nvidia ones are months/year or so old, with nvidia drivers i'm on a 'if its not broke don't fix it' due to how horribly that crap handled my monitor, kicking to a black screen 5-6 times a day, now don't get me wrong, scrubbing a video will throw system error more than most things I do amd or nvidia, but 6 times a day was just not acceptable so the first driver that solved the issue I go it and till something breaks in a way I can confirm its gpu related, i'll stay on it.

yea saw ya in hydrus discord so I figured it would be easier to get some help there,

image is my final numbers, those seem to be in line with what you think they should be or is there still some area to cut fat?

scrubbing video on my computer will sometimes cause the monitor to stop working, a monitor restart will fix the issue, but hydrus tossed these errors along with it so though I should report them.

Anonymous Board owner 10/06/2019 (Sun) 22:03:55 Id: 49f621 [Preview] No.159 del
Thank you for this report. I will check this out. I wonder if I am already inserting a secondary sort of media_viewtime or similar that is not causing conflicts and falling back to the 'random' secondary you have set.

Anonymous Board owner 10/06/2019 (Sun) 22:12:50 Id: 49f621 [Preview] No.160 del
Thank you for this report. This is unusual. Can you try turning on help->debug->report modes->subprocess report mode and trying help->about again? This should dump a whole bunch of environment info. If you compare this between installs, are there any obvious differences?

Normally, it should not matter where the db folder is, since it is targeting install_dir/bin/ffmpeg, and I haven't seen problems here for Windows before, but obviously something odd is going on here.

Is there any chance that your client/OS has lots of threads/processes open? This specific WinError 6 can be due to too many processes being open and Windows not being able to open a new one. Could it be, say, that hydrus had reason to created hundreds of new video thumbnails recently? Or do a lot of background file maintenance?

I am updating my 371 FFMPEG about window error reporting to name the FFMPEG path, just so we can check this is pointing to the right location.

Anonymous Board owner 10/06/2019 (Sun) 22:16:25 Id: 49f621 [Preview] No.161 del
Yeah, that db size looks great. A vacuum may shrink client.master.db a couple gigs, but that looks normal for a heavy db with millions of files.

We'll be on Qt in six weeks, so with luck the whole UI will be drawing pixels to screen in a more reliable way. Please let me know if your freezing and other weird behaviour improves/changes when that happens.

Anonymous 10/07/2019 (Mon) 00:44:31 Id: 605a00 [Preview] No.168 del
I'm running Win7x64 and testing with empty dbs so I don't think there's any reason for Hydrus to be making any calls.

The only difference in the env vars was that the separate db instance had an extra line:

The odd thing is that I ended up getting Hydrus to run from source with Python 3.7.3 and the problem doesn't occur at all. Other than extra pipenv env vars, there weren't any obvious difference in env vars between my source instances and the compiled instances.

I'll test 371 when it drops and see what ffmpeg path is generated and go from there... maybe try my own builds with pyinstaller and track down the problem with my machine.

Release Tomorrow! Anonymous Board owner 10/02/2019 (Wed) 02:45:36 Id: a91aab [Preview] No. 144 [Reply] [Last 50 Posts]
I had a great week. As well as a variety of fixes and little improvements like new 'duration' icons on thumbnail and system:modified date, I finished the first version of the new tag display/filtering system. You can now hide specific tags and namespaces from the 'tag selection' and media viewer lists separately, and a variety of tag tasks like media selection in a big thumbnail view are a bit faster. There is also an important fix to the new asynchronous tag repository processing.

The release should be as normal tomorrow.