[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]

/hydrus/ - Hydrus Network

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

Catalog

8chan Bitcoin address: 1NpQaXqmCBji6gfX8UgaQEmEstvVY7U32C
The next generation of Infinity is here (discussion) (contribute)
Name
Email
Subject
Comment *
File
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Embed
(replaces files and can be used instead)
Options
Password (For file and post deletion.)

Allowed file types:jpg, jpeg, gif, png, webm, mp4, swf, pdf
Max filesize is 8 MB.
Max image dimensions are 10000 x 10000.
You may upload 1 per post.


New user? Start here ---> http://hydrusnetwork.github.io/hydrus/

YouTube embed. Click thumbnail to play.

 No.776

win32

zip: https://github.com/hydrusnetwork/hydrus/releases/download/v159/Hydrus.Network.159.-.Win32.-.Extract.only.zip

exe: https://github.com/hydrusnetwork/hydrus/releases/download/v159/Hydrus.Network.159.-.Win32.-.Installer.exe

os x

app: https://github.com/hydrusnetwork/hydrus/releases/download/v159/Hydrus.Network.159.-.OS.X.-.App.dmg

tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v159/Hydrus.Network.159.-.OS.X.-.Extract.only.tar.gz

linux

tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v159/Hydrus.Network.159.-.Linux.-.Executable.tar.gz

source

tar.gz: https://github.com/hydrusnetwork/hydrus/archive/v159.tar.gz

I had a very good couple of weeks. In case you missed it, a giant update was causing clients to crash from memory overload, so I shut down my server and put off last week's update to get a good fix done.

So, I have completely rewritten the update network protocol for hydrus, including how updates are generated serverside and stored to disk, to keep memory and cpu costs low. In my general testing, memory usage stays below 50MB (before, the problem 1.1 million tag update attempted to reserve many GB of memory and hence was crashing the client), and converting an update between a network string and a useful object is about two hundred times faster. Even better, I have saved about 30% on bandwidth.

Because of this important change, this release increments the hydrus network version, which means that v158 clients cannot talk to v159 servers and vice versa. I am turning my server back on today, and if you would like to keep syncing, you will have to update your client.

Furthermore, your client will have to redownload every update for every repository it syncs with. It will not have to reprocess those updates, only download them. For my public tag repo, it'll be about 220MB.

update rewrite

Essentially, I have done two things: I have changed my serialising library from YAML to JSON, and I have split large updates into smaller pieces.

YAML is a great protocol, and PyYAML is a great library that supports it, but it was not working for my purposes. It was really quite slow at doing what I wanted, and it did not allocate memory very efficiently as it parsed. I have scrapped it for the new JSON stuff I have been slowly moving to, which is reliably extremely fast and lean, and my new system allows for easier upgrading in future.

Very large updates are now split into blobs of about 100,000 'rows', where a row usually means something like a tag-file mapping. These sub-updates peak at anything from 1MB to 4MB, which is generally much easier and less laggy to deal with en masse than a giant 15MB+ chunk.

I am very glad I took the extra time to get this right. I would never have been able to get it out on Wednesday in any proper state.

I do not know how many people use hydrus, but I am obviously expecting a bit of a bandwidth rush with all the people who will be resyncing over the next week. If you encounter server errors, please pause your repo sync for a bit and try again later, and let me know what error text or delays or other experiences you have!

Furthermore, I have added a rows/s (i.e. rows per second) report to the normal update processing popup. I tend to get about 250 normally, and 1,000 or so on idle mode. I would be really interested in knowing what other values people get for this. I am also interested in knowing whether you are on a laptop or a pc, and whether it is a particularly powerful machine, whether you are on HDD or SDD, and whether the drive is encrypted or not.

tag export and import

I have ditched the old tag export and import YAML stuff for my new tag archives system.

If you want to export a bunch of tags to another client, just right click some thumbnails and select share->export->tags. This now creates a tag archive, which is just an efficient database file for storing tags.

You can simply import such a tag archive from the main gui's file menu.

4chan dumping disabled

I haven't touched my dumping system in a very long time. Some people told me it wasn't working, as 4chan's captcha has changed or something, and as I don't have time to fix it, I have disabled it. I would like to bring it back with better support for other imageboards.

idle mode

Usually after about twenty or thirty minutes of you not doing anything, the client turns on 'idle mode', which tells update processing to work in superspeed at the expense of making the gui laggy. You can now see when you are in idle mode from the status bar, and you can force it from the help->debug menu.

full list

- split previously monolithic repository updates into smaller pieces

- added service_update server calls

- extended content_update server calls to support sub-indices

- sped up some content update preprocessing code

- improved some content update preprocessing code

- radically reduced serverside memory usage while generating updates

- added iterator splitters to make sure any single update row cannot be too large

- thanks to iterator splitter, updates should process through the client more smoothly

- added timespan splitter to make sure any single server update query cannot be too large

- content updates are resumable if broken part way through downloading the list of them

- the update popup will state how fast it is currently working in rows per second committed

- cleanup of a lot of update related code

- more cleanup of update related code

- improved serialisable protocol so it'll work better over a network

- made serialisable protocol much simpler

- fixed numerical rating system predicate dialog slider range

- fixed numerical rating system predicate dialog OK for valued predicates

- fixed numerical rating custom filter action dialog

- improved some network yaml error handling

- replaced 'export tags' thumbnail menu entry with a tag archives system

- replaced 'import metadata' file menu entry with a tag archives system

- disabled thread dumper and manage imageboards and manage 4chan pass dialogs for now, because dumping code is out of date and completely screwed up

- client will now not start in idle mode

- help debug menu has new 'force idle mode' entry

- idle mode is displayed on status bar

- simplified client main gui status bar display and code

- the flash and flv files' embed button now has a little border to delineate it from the canvas background

- fixed some clientside bandwidth tracking code

- removed some old networking code

- made some custom objects draw themselves more efficiently

- for now, manage tag parents and siblings dialogs will not show deleted rows. I will eventually add a 'show deleted' checkbox, like the manage tags dialog has

- some static image rendering is slightly less laggy, particularly when browsing large images

- fixed initial height of manage tags dialog launched from preview window

- changed the 'search area' vs 'preview' sash gravity so the preview area won't expand or shrink on resize–see if you like it

- autocomplete dropdown should now hide itself when focus goes to other programs

- autocomplete dropdown should now hide itself when focus goes to other hydrus frames in os x

- fleshed out new URLCache object to handle better gallery download url management

- refactored some file status tracking stuff to a better system

- refactored gallery page fetching to a better system

- refactored gallery url handling to a better system

- some redundant import checking should be much faster

- improved error handling when booru image page parsing fails to find image url

- refactored how tags are fetched for DA, tumblr, and giphy as part of the above overhaul

- misc code cleanup

next week

I want to get back to adding Socks proxy support. I could have tried to do it yesterday, but I faced the same dilemma as last week, where I realised that the amount of work it will need means I should not rush it. So, I will do a generic network engine upgrade and then add proxy support, and then just work my list. I want to add those ratings colour options, improve the 8chan thread watcher for multiple files, fix some non-windows issues, continue a multi-month file downloading/importing rewrite, add a recycle bin service, and fifty other things.

With this semi-milestone release, I'd also like to generally say a renewed thank you to everyone for using my program. It is great hearing about the ways you use it and what you would like to see in future, and even though this recent problem took some time to fix, I really enjoyed the work.

 No.778

Trying out the linux version, this happens whenever I try to import a webm

Same for 158

Database Error!

/tmp/hydrusd1VlLq not found ! Wrong path ?

Stack Trace (most recent call last):

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/threading", line 783, in __bootstrap

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/threading", line 810, in __bootstrap_inner

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusThreading", line 181, in run

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.ClientDownloading", line 1176, in call

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusController", line 155, in WriteSynchronous

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusController", line 45, in _Write

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusDB", line 302, in Write

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusData", line 1159, in GetResult

Traceback (most recent call last):

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusDB", line 166, in _ProcessJob

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.ClientDB", line 5952, in _Write

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.ClientDB", line 3763, in _ImportFile

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusFileHandling", line 175, in GetFileInfo

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusVideoHandling", line 46, in GetFFMPEGVideoProperties

File "/home/hydrus/Desktop/hydrus/build/client/out00-PYZ.pyz/include.HydrusVideoHandling", line 184, in Hydrusffmpeg_parse_infos

IOError: /tmp/hydrusd1VlLq not found ! Wrong path ?


 No.780

File: 1433447012410.jpg (680.34 KB, 728x1181, 728:1181, ebf58f7c93e17bf13eefffff4b….jpg)

>>778

Thank you, I will look into this.


 No.782

File: 1433455189740.jpg (280.85 KB, 600x450, 4:3, c7a902b084832919b84307f086….jpg)

Hydrus_Dev, who is your waifu Desu ka~


 No.783

can this dumping feature you speak of be ported to 8chan?

I assume its a basic dump system that dumps selected files into a thread?

Ive wanted one of those for a long time

many of 8chans boards do not have captcha


 No.784

>>783

From the 8chan faq, under "Can I have a list of all API endpoints for getting raw data from 8chan?":

>Endpoints not listed here, like post.php, catalog.json or boards-top20.json are subject to change or removal at any time!

It may be too much effort for hydrus_dev to try to keep up with the newest post protocol. That, and we might be seeing 8chan move to infinity next soon.


 No.785

File: 1433537934890.jpg (127.85 KB, 861x474, 287:158, 75b5601d04acec4e05490229ab….jpg)

>>782

Motoko 4 lyfe.

>>783

That is the hope. I would like to make a system that users or I can more easily expand to any imageboard just by describing the POST form. The old system did this somewhat, but not very flexibly. As >>784 says, this stuff is difficult to keep up with–without an official API, trying to parse errors and so on is a giant headache. When I rework it, I will try to make it easier to keep up with changes.


 No.786

File: 1433645477835.jpg (19.07 KB, 482x321, 482:321, 1432772728304.jpg)

>>785

12/10 taste

You could try to contact hotwheels through git or /operate/ (there's een a thread about directory dumpers) or n-tech about the infinity next engine were getting soon, so we could have this function off the bat when it is finished perhaps

Also any advice for putting hydrus on a vps?


 No.787

File: 1433709935405.jpg (570.24 KB, 900x1271, 900:1271, 6e76e1b170b0a302379d38ecb9….jpg)

>>786

Oh and another question, is it somehow possible to update hydrus to download pictures on pixiv that are part of multiple picture galleries?

There are a lot of images out there in those little collectoins, so im missing out on a lot of pictures when I download a tag


 No.788

File: 1433723978976.jpg (4.27 MB, 2000x3236, 500:809, 1d5555b2f5120d8ad3b5704c14….jpg)

>>786

I don't know much about what you can do with VPS these days. My guess is that it can't be done, because I assume that unless you spend a lot of money, they'll only offer you the ability to run PHP or perl scripts through some CGI thing, whereas the hydrus server is a full binary executable that wants to take a whole load of file and port permissions that they won't permit. I designed it to run on a spare computer under a desk, like Filezilla Server, so I don't expect it will work in the general enterprise/hosting space. If you figure out a way to get it to work though, I'd love to know the details!

>>787

This is something I keep meaning to get back to, but it is so finicky and idiosyncratic that I keep putting it off. I also don't use pixiv myself, so I don't encounter the problem personally and don't remind myself. Several people have asked though, so I will make a note to dig up my old pixiv login and recheck the html for those galleries.


 No.789

>>788

There are four kinds of downloads on pixiv that I know of and each uses different applets to display them.

Images are just regular single images. Clicking on them changes between regular and full screen.

Manga has the little pages behind the image. Opening them goes to a vertical list of images with little buttons next to them to show the full size version.

Comics have a horizontally oriented applet with a page flicker for showing facing pages. They're rare and I don't know how to download them.

Animations are interesting. They're implemented as a zip file full of png or jpg files for every frame of the animation. On the main page for the artwork there's an applet that loads the zip file in the background and shows the images in order to make the animation. You can download the full sized zip file by opening the Javascript console and entering:

window.location=pixiv.context.ugokuIllustFullscreenData.src

The current code for importing creator and title tags is pretty buggy also. I hope you can make all this work.


 No.790

File: 1433784869840.swf (2.75 MB, 7e5c1b93b9531a2d90c44d1f3c….swf)

>>789

Thank you, this is very helpful!


 No.791

>>786

If you are talking about cloud servers like those DigitalOcean and Amazon provide, you should be able to just run the server executable, and it should work.

I'm not sure if the server executable is provided in a GUI-less manner (could you please provide this, hydrus_dev, it would ease server management so much?), so you would properly need either windows or a x-server, and the required remote desktop tools to manage it.

If you are talking about a shared server, or some other dumb cloud server where you don't have full control of the operating system, like >>788 think you are, then no, there is no advice, because it is properly impossible. Cloud hosting is crazy cheap now, just get an AWS or DigitalOcean server and host it there.


 No.795

where is the database of images stored?

i just imported a bunch of files but im not sure where they went actually on my pc

thjanks


 No.796

>>795

In the hydrus network folder is a subfolder called db. The database is the client.db file and the files are linked to it by their filenames in the client_files folder. Hydrus calculates the hash value for each file you import and it copies the file into one of the client_files folders, then it renames it to the hash value it calculated

Don't be surprised that you don't recognize the filenames. You basically throw away the filename when you import the file by default. If you want to keep the filename, you can add tags before importing and add a namespace tag for "filename" using the regular expression (regex) in the menu there. Clever regexes can pull the titles, volume and page numbers, author info, etc. from the filenames during the import.


 No.798

File: 1433897954158.jpg (854.97 KB, 1551x2193, 517:731, 2dde07ffc21de71793abff7d7c….jpg)

>>791

Would something like:

server -start

server -stop

server -restart

work for you? I don't know much about server management–is there a standard for this sort of thing? The server's controller is a wx app, so I don't know if that demands an x-server just to instantiate, but we can try.


 No.800

>>796

I guess what I'm asking is, where is the file that I can move around, i.e. cut and paste in a different drive or put on a flash drive?


 No.801

>>798

What I would like to have is just a very simple command line interface, where I can get some basic information about the server's status, and do some commands. I'm not sure how this would be accomplished through the wx app, or if wx fuctions properly without an x-server.

>>800

Your files can be found in the hydrus/db/client_files folders.


 No.802

>>789

This reminds me, does downloading webms from danbooru work in hydrus or is it still borked? They actually store zips for animations they get from pixiv in the same way as pixiv does, and I believe they actually do the same background animation thing with them, but you can also choose to view a pre-rendered webm.


 No.803

File: 1433954790957.gif (2.81 MB, 336x175, 48:25, fc065c89db73b4e59ee16c6f66….gif)

>>802

I haven't specifically fixed this, so if it was once borked, it likely still is. A normal zip might be unzipped, and every file imported in turn, but it might also break. I'd rather specifically catch the webm link. Can you give me a link to a danbooru page like this, so I can test my parser?


 No.804

>>802

At least on pixiv, those pre-rendered displays were ~50% the resolution of the full size images in the zip file. I'd rather have the zip file and make the webm myself, personally.

Did danbooru resize the webms when it created them?


 No.807

>>804

I'm… not sure, actually. Lemme check.


 No.808

>>804

>>807

http://danbooru.donmai.us/posts/2035641

The webm and view original (below the image) versions are the same resolution. The zip file also has images of the same resolution. So no, I suppose.


 No.809

File: 1433957838981.jpg (86.91 KB, 800x600, 4:3, project.jpg)

>>808

Well, the real question would be do we want to use danbooru's webms in the database. If gelbooru or whatever other site started doing the same thing, the encoding would almost certainly be different such that Hydrus wouldn't consider them to be the same file, even though they came from the same source.


 No.810

>>809

There is the large problem of Gelbooru only starting to accept webm uploads very lately, and they don't mirror ugoira uploads like they do regularly… Some users have started uploading ugoiras of certain artists, but I have no idea if they're the danbooru ones or self-converted. I don't know, I really doubt gelbooru will ever get ugoira support. It's a lot of work that is ultimately very pointless.

I have to congratulate the pixiv dev team for inventing an animated format more inefficient than GIF.

At least it supports more colors than 256. I especially love when people post gifs of their source filmmaker animations, 1080p, 5 seconds long… 60 mb gif. With a shitty color palette. Good job.

I hate gifs.


 No.813

File: 1433973442147.png (17.14 KB, 595x208, 595:208, 2015-06-10 14_56_29-db.png)

thanks but this is all I have in my db folder


 No.814

>>813

meant for>>801


 No.816

File: 1434047259206.png (19.79 KB, 586x282, 293:141, 2015-06-11 19_48_53-db.png)

>>813

>>814

That is very bizarre. It should look something like picture. Yours look like a completely new installation of hydrus, the database file and the file folders are created at the first run of the program.

Could it be that you have two separate installations of hydrus, and you are looking in the database for the wrong one?


 No.819

File: 1434156933182.gif (1.44 MB, 400x225, 16:9, 199defcafe4deb954a7da14576….gif)

>>804

>>808

>>809

I don't like the idea of importing 'samples', if I can help it, so I would rather get the fullsize frames and convert myself than be satisfied with the 50% version. I currently convert from bmp->png on import because png does the exact same job for much less space. Perhaps I should write a ugoira->webm routine in the same intention, although I am not sure if that would be easy to do multiplatform. Maybe FFMPEG can do it.

I am not sure of the point of ugoira, except I guess if you have pngs it is lossless? If that is so, and if it matters to people, I could just add ugiora support.


 No.821

>>819

ffmpeg could certainly do it (there's not much it can't do). After some research however, it turns out that VP8 depends on nondeterministic temporal shifting unless you enable –debug. That means you'll never be guaranteed to get the same file without debug's inefficiencies, though that may not be a high price for such relatively small files.

I certainly see the value of using small webms for stuff like thumbnails, however.


 No.822

>>810

Inefficient maybe, but if the idea is to keep the original lossless files available, it makes some sense. webm was supposed to fill the void left by the failure of PNG animation formats, but we're now realizing the limitations of it, particularly its nondeterministic nature.


 No.823

>>819

>I currently convert from bmp->png on import

Hydrus does this automatically? I've been waiting to import a couple folders full of bitmaps until I could convert them myself, but if I don't need to do that, all the better.


 No.824

File: 1434208685986.png (34.36 KB, 1278x784, 639:392, 2015-06-13-102737_1278x784….png)

>>801

Pretty sure wx can't function without an X-server. I have to run Xvfb just get to get it work headless, which eats up a lot of RAM just to have hydrus running.

And then to get it to quit gracefully I had to modify the server.pyw file to catch the interrupt signal and then threw the mainloop into another thread. (pic related)

Best bet is to split the server logic into gui and regular routines (although I think hydrus dev is relying on wx for a bit of the server logic), then have it detect if a graphical environment is possible. Or perhaps have the server just be console only?

As for standard signaling in terms of headless servers, as far as I know, I don't think there is such a standard. Most distros package scripts or use systemd to either pass commandline flags to processes or send POSIX signals. In the case of game servers a lot tend to implement their own sort of interactive commandline, which would probably be overkill for hydrus. Commandline flags would be fine for hydrus.

Headless hydrus server would be REALLY nice though.


 No.825

File: 1434243118050.png (60.55 KB, 914x805, 914:805, 2015-06-14 02_46_39.png)

>>824

Splitting into routine/backend and GUI/frontend modules would solve it, and give power users (with programming skills) much more freedom to manage their stuff, however they want to.

Something like picture could work fine. Have some callback hooks in the backend, let the frontend set those callbacks, and voilà, you got a system where you can change the interface easily. Heck, if you want, you could easily make it multi threaded, while you're at it. (Or even networked, which would really be icing on the cake.)

Not entirely sure how large a code change this would be though. Properly way too large to even consider.


 No.826

File: 1434299747853.jpg (204.3 KB, 640x480, 4:3, 914af32bcf019ae90b3438dc1c….jpg)

>>801

>>824

>>825

I have added a project to my cleanup to-do list to extract wx from my server. I will have it control through the command line and create a separate tiny notification icon control exe that'll interface with that to replicate existing behaviour.

Other than the notification icon/window, in the server I only really use wx for some simple controller stuff and pubsub, which I can switch over to a custom object without too much trouble.

If I am feeling clever, I will look into how to register the server as a windows service as well, so it boots with windows. I think InnoSetup can do this.


 No.827

>>819

Not sure if you'll notice this, but the "Sample" webms on danbooru are actually full-size, unlike the previews on pixiv. Just to clarify. Downloading the zip itself and converting it "clientside" has the problem with non-deterministic behavior…




[Return][Go to top][Catalog][Post a Reply]
Delete Post [ ]
[]
[ home / board list / faq / random / create / bans / search / manage / irc ] [ ]