[ / / / / / / / / / ] [ dir / cute / egy / fur / kind / kpop / miku / waifuist / wooo ]

/hydrus/ - Hydrus Network

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

Catalog

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 12 MB.
Max image dimensions are 10000 x 10000.
You may upload 5 per post.


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

Current to-do list has: 714 items

Current big job: finishing off duplicate search/filtering workflow


YouTube embed. Click thumbnail to play.

32ca8c No.5246

windows

zip: https://github.com/hydrusnetwork/hydrus/releases/download/v245a/Hydrus.Network.245a.-.Windows.-.Extract.only.zip

exe: https://github.com/hydrusnetwork/hydrus/releases/download/v245a/Hydrus.Network.245a.-.Windows.-.Installer.exe

os x

app: https://github.com/hydrusnetwork/hydrus/releases/download/v245a/Hydrus.Network.245a.-.OS.X.-.App.dmg

tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v245a/Hydrus.Network.245a.-.OS.X.-.Extract.only.tar.gz

linux

tar.gz: https://github.com/hydrusnetwork/hydrus/releases/download/v245a/Hydrus.Network.245a.-.Linux.-.Executable.tar.gz

source

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

I had a very busy three weeks overhauling the network and much else besides.

This release increments the network version. v244 and earlier clients will not be able to talk to v245 and later servers and vice versa.

network overhaul

This took two weeks longer than I wanted it to, but it probably had six times as much work as I expected. Every old creaky part of the network I improved revealed a critical link that was A) just as bad and B) had to be updated or else nothing would work. Github reckons I made 14,380 additions and 10,911 deletions. A typical single week has 600/300, which shows at the very least that I typed a lot more than usual. I ended up putting in a lot of hours and exhausting myself for v245, but I ultimately had fun, and I am really happy with the overall result.

The technical upshot is that the network runs better, faster, and uses far less bandwidth. The repository update process–which is the overwhelming majority of all network traffic–now uses about 23% of what it used to, and it runs on a new philosophy that allows much better scaling in future.

Repository processing now occurs in a more sane way and inside single database transaction, meaning it will not pause to save every 100,000 rows. Processing the entire PTR should now only take 1-2 hours on a typical PC.

'Services' objects are also completely rewritten, and review services and manage services along with them. These panels let you do more and show more information–you can now pause repositories and also force processing from review services.

Bandwidth tracking and enforcement is improved as well. Services that connect to the internet and accounts for repositories now know how much data they use and support multiple flexible rules for when to stop doing heavy lifting. These new bandwidth controls will soon appear in more places across the program.

If you are a server administrator, you now have these bandwidth controls for your services and account types–please check them after updating to make sure they are set how you like.

unfortunately a full resync is required

Unfortunately, the changes are so significant that the old update files cannot be converted. Your clients must resynchronise with their repositories. For my public tag repository, this is now about 620MB of data (down from 2.8GB!). I have set a 250MB/month and 50MB/day limit on existing repositories just to smooth out the hump of all of us resynchronising. Please feel free to remove these restrictions under manage services when things calm down.

If you are a pro user and sync with the PTR, please download this: http://www.mediafire.com/file/1s1ee30fk27ejc9/ptr_update_files.7z , extract it somewhere, and then import its contents via the new menu entry services->import update files. This skips you having to download the files through the network and saves me a bit of bandwidth. Thank you!

some things don't work yet

Despite all the work, there is still some more to do. Review services and manage services still have some placeholder panels, and I haven't had time to fix/update some database maintenance and network administrative functions. Please hang in there as I reintroduce these things over the next few weeks.

I tested this extensively by myself and then tested it again with users. I have cleaned out many bugs, but there are likely others. Please report them and I will turn them around as quickly as I can.

full list (you do not have to read all this)

- fixed a v244 update problem for clients updating from <v238

- some misc stuff:

- if you start editing many subscriptions, cancelling a single dialog will break the chain of loading new dialogs

- reduced some redundancy in regular client file import

- improved how the dialog for selection from a list of strings works

- if the client ever merges one directory to another (such as in external file locations migration) and any files fail to merge, the source will no longer be deleted

- created new flexible bandwidth tracking and ruling objects

- updated how repository updates work, splitting the old explicit and self-contained content update package system to a new implicit definitions/content split system and an improved one-step-sync metadata propagation

- updating now takes approximately 23% as much bandwidth as before

- update files are now stored in client_files and server_files like any other file (client_updates and server_updates folders will be deleted on update)

- the server will print update generation info to its log

- unfortunately, updates cannot be converted, so a complete resync of update files is required. the smaller update size and better bandwidth controls should mitigate the problem somewhat

- the server has been compacted across all content types–its mappings db file should shrink about 12%

- due to new service-specific ids, server.master.db should increase in size, typically about 50%

- harmonised how GET and POST/response args are built and parsed across the network

- server administration initialisation is now simpler, done with 'init' registration key

- leading and trailing spaces are now removed from both the namespace and subtag components of namespaced tags, meaning 'title: blah' will be collapsed to 'title:blah'. tag repositories will clean their existing tags on update

- invalid serverside tags will be replaced with valid placeholders on server update

- refactored, harmonised and simplified some server request code

- Eris makes a triumphant return to the root welcome page ('/' request of any service) with improved self-description text as well

- updated how bandwidth is tracked and overseen

- all requests now consume bandwidth

- fewer requests are actually constrained by bandwidth–at the moment, it is only update files and file/thumbnail downloads, as these represent the overwhelming majority of bandwidth consumption and are not at all critical to service operation–this may change in the future, but it suits our purposes for now

- bandwidth tracking code is more sane across the board

- the server's administration service now tracks server-wide bandwidth as it happens

- service and server-wide bandwidth rules are consulted as soon as the request begins

- improved some server response rendering

- permissions are more flexible and content-specific

- improved how file repositories check and process file requests

- created a gui control for managing bandwidth rules

- updated the serverside service object

- the serverside service object now contains bandwidth rules and tracking

- updated how the server deals with services on a db level

- refactored and cleaned a ton of server db code

- updated how services are edited over the network

- updated how the server associates its services with its http pipeline

- converted clientside server service management gui to the new panel system

- updated gui code for clientside server service management

- converted clientside server service management db code to the new system

- improved how bandwidth errors are reported

- updated the account type object

- the account type object now contains bandwidth rules and a more flexible permissions system

- updated how the server deals with account types on a db level

- converted clientside server account type management gui to the new panel system

- updated gui code for clientside server account type management

- serverside account types are now fetched from a cache, reducing memory sprawl

- updated the account object

- the account object now contains a bandwidth tracker

- updated how the server deals with accounts on a db level

- updated the clientside server object

- the clientside server object now contains bandwidth rules and a tracker and has improved error management, recovery, and reporting

- updated how the client deals with services on a db level

- improved how serverside bandwidth errors are caught

- all clientside services start with a 50MB/day bandwidth limit

- existing repositories will get a 250MB/month, 50MB/day default bandwidth limit, just to help us get over the hump–see the release post for info on how to get all the updates anyway

- updated manage services dialog extensively

- service account registration now occurs through a simple button on the normal clientside service edit panel

- all services can now be renamed

- updated the content processing pipeline

- prepared code for future merging of file and tag repositories

- added future support for pend-petitions for files and mappings and simple creation permissions for tag siblings and parents

- the clientside content processing pipeline now operates inside a single database transaction, reducing a great deal of previously redundant hard drive activity

- the serverside content processing pipeline now creates per-service timestamped content definitions

- the clientside content processing pipeline now maintains and appropriately consults a cache for server definitions

- pre-process disk cache is more intelligent

- updated review services to match the new service objects

- service review panels now show more information about error state and so on

- service review panels should now update as soon as services change

- you can now force sync repositories from review services

- you can now pause/resume repositories from review services

- you can now export repository update files from review services

- you can now import repository update files from the services menu

- repository thumbnail download now uses a cache for faster thumbnail ownership testing

- culled a lot of old code and experiments

- deleted all the old messaging depot code and db table cruft

- removed optimised petition processing

- serverside deleteorphans is temporarily disabled

- hydrus client-repository relationship no longer supports news

- removed the 'stats' admin service call–it will come back as a account review page

- clientside clear orphans is temporarily disabled

- clientside local file/thumbnail server is disabled for now

- custom service 'messages' for the root page are no longer available

- some things are not working yet–they will be back in soon

- content presentation on review services

- service reset, other advanced content service controls

- ipfs controls on review services

- local booru controls on review services

- most service-specific panels on manage services

- petition resolution

- serverside account modification, including banning

next week

I now have three priorities: catching up with the urgent bugs that have piled up in the past three weeks, finishing off the placeholders of this overhaul, and resuming duplicates. I'd like to fit in a little sleep as well.

dbc1eb No.5247

>>5246

>I ended up putting in a lot of hours and exhausting myself for v245, but I ultimately had fun, and I am really happy with the overall result.

Glad to hear you like what you're doing dev, the update notes have been increasingly fantastic as I've followed and used Hydrus


40f61f No.5248

>>5246

>>- serverside account modification, including banning

H-has someone pissed you off?


37f639 No.5251

File: 43c0d423825828b⋯.jpg (97.1 KB, 1137x640, 1137:640, Finally realizing cirno is….jpg)


44b540 No.5252

I'd really like you to prioritize duplicates.


f9a3c9 No.5253

I updated to the new version and used the download you provided to update the PTR. It took a while but everything seems to be working well.


4579cc No.5255

>>5246

Something seems to have come up in a previous update, is there any way to set default local tag autocomplete to "all known tags" instead of local tags? Local tags seems to not want to show the true number of tags in autocomplete while in the "manage tags" dialog


29869e No.5260

Pixiv does not work for me, i'm on 245a.

Error: "Did not work! ForbiddenException('Pixiv login credentials not accepted!',)"

Tried with id and email, password works (tried on pixiv website)


dac559 No.5261

>>5246

I would like to implement read-only syncing to Hydrus tag repos. Where can I find the relevant implementation, particularly the network protocol and payload structure?


6268fb No.5262

File: c3bc5c3e8e9d772⋯.jpg (52.58 KB, 540x720, 3:4, 1429675668238-0.jpg)

File: 1c1fd4349383aaf⋯.jpg (52.84 KB, 540x720, 3:4, 1429675668238-1.jpg)

Yay!

Also that's a really cute video.


5b03e5 No.5266

File: aa9357f80e2186e⋯.webm (282.01 KB, 360x360, 1:1, aa9357f80e2186e61a6282114….webm)

Sorry for late reply here folks. I had a bunch of IRL stuff to catch up on that was stressing me out.

>>5247

I'm going to put more time into test code and code cleanup in future. I'm happy with the volume of my work, but I do hate the typo bugs.

I do enjoy coding though. More and more, as I get better at it.

>>5248

I didn't forat my changelog great here. In my todo list it was broken into seven or eight sections, mostly headed by the 'updated how blah works', and then those last bits are all under 'some things are not working yet'. A bunch of admin stuff like petitiion processing and user banning isn't working yet.

A far as I can tell, bad user behaviour has not been a problem yet on the PTR. If someone is adding bad tags, their actions have been completely swamped by good content and honest mistakes.

>>5255

There isn't an option to do this yet. I will add it to the list.

I've fixed some of this code for v246. Please let me know if your counts are still off after an a/c cache regen next version.

>>5260

I am not sure about this–it works for me. I use my 'username', not an email address–do you use an email address? Maybe the '@' symbol is getting borked or something?

Also, are you on Linux/OS X? There seems to be a pixiv SSL issue for them that I'm also trying to figure out.

These 'hydrus is not acting like a nice browser' issues may be magically resolved when I overhaul the downloader engine.

>>5261

I've just rewritten pretty much everything for this release. If there is some documentation hanging around the help folder, it is probably invalid right now.

Everything is now in hydrus-specific json that (de)serialises hydrus objects. If you are using python, you might be able to cobble my currently scattered and messy code into an API you can plug into, and if you aren't, you'll have to see how the code works and walk through all those json tuples yourself.

Although it is a mess right now, it was apocalyptic before. From now on, I intend to put a little time in every week to clean and refactor the code into something more sensible over the coming weeks. For now, most of the fun is in HydrusNetwork.py. If you just want to grab updates, you'll want to do something like:

Get a session key with your hydrus access key, which means going GET /session with http header "Hydrus Key" : "abcdef…" and getting the hex session key as a cookie back. Use this session key as a cookie in future requests.

Go GET '/metadata?since=0' to get a metadata object, which will include update hashes encoded as hex.

Go GET '/update' for all those hashes you don't have and save them somewhere.

Figure out which updates are definitions and which are content. Process the definitions first, then the content.

All the GET responses will be zlib zipped json.

Working with my objects will probably be a giant pain in the neck, so please feel free to ask me for help on any of the specifics.

I expect future versions of the network to have easy API calls for outside script writers.


894c1e No.5284

>>5266

Having trouble with the very first step. Maybe I'm doing something wrong. So to connect to the default public tag repo I send a GET request to http://hydrus.no-ip.org:45871/session with the header "Hydrus-Key: 4a285629721ca442541ef2c15ea17d1f7f7578b0c3f4f5f2a05f8f0ab297786f"? Doing that only returns an empty response, no status code, no nothing. Can't find the relevant parts in the source either.


4c2a68 No.5285

>>5284

Shit, sorry, the call is /session_key . That header looks correct.

Also, the update call should be:

/update?update_hash=abcdef…

Check ServerServer.py in the include folder of any release for the starting place of all this gubbins.


19108c No.5286

>>5284

Oh, and do https (I think that's why you are getting no response at all), and don't verify the https certificate as it is self-signed.




[Return][Go to top][Catalog][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / ] [ dir / cute / egy / fur / kind / kpop / miku / waifuist / wooo ]