/hydrus/ - Hydrus Network

>>13894

Anon, you could have a seperate user account on your OS that you keep logged in that handles the client.

PSA to all anons using the new e621 api downloader: you need to manually fix all of its tag.producing content parsers to turn underscores into spaces.

I've noticed because someone dumped a bunch of underscored tabs in the PTR.

>>13894

You know, I could tie this into the new system tray icon. Just add an option, if you have a password set, to 'lock to system tray', and then require the pass to open up again.

For font size, I have been doing a couple of custom tests with other users, and I hope to roll out some 'official' solutions once I have better support, but yeah, so far the best luck I have had is with a custom stylesheet. Routine I have done is creating a new 'my_custom.qss' file in install_dir/static/qss, with the following text:

/* You can set the pt value to whatever you like */

QWidget
{
	font-size: 14pt
}

And setting that qss in options->style. Did you try something like that, and it still didn't work for you? A few of my custom controls do not follow the font size when set this way yet, but I expect to fix them.

I had a mixed week, but I am happy with my work. The first step in faster and more accurate tag siblings at the database level is done and plugged into tag autocomplete. I also sped up some common database operations, fixed a heap of bugs, and did some quality of life improvements.

The release should be as normal tomorrow.

>>13907

I just wanted to say that this worked, I maybe had a typo in the selector or property for my qss. Thank you very much.

I think there's utility in being able to lock the client, but the client also pulling down subs/galleries at the same time

>>13841

Hey, sure–the main tool you want here is a 'Hydrus Tag Archive', which is a portable tag database you can import from or export to. You can generate one of these using services->tag migration. In your old client, move all your tags from 'my tags' for 'my files' to a new HTA, and then import that HTA to the new client using the same dialog, but this time set it for 'all known files'. When you export/import your files over to the new client, your tags should be waiting for them when they arrive.

This is an advanced operation, so make sure you have a backup of everything before you do it, and let me know if you run into any trouble.

Thanks! Worked like a charm! I was afraid of trying it before, because the greyed out option said "delete". :)

Hello hydrus_dev, the danbooru file page parser broke again and wasn't finding file url's, but I fixed it.

"section id=image-container" simply needs to be changed to "section class=image-container" and it works fine.

Seems like they've been fussing with the page layout, so who knows whether this change will stick.

AAAAHHHH I MISSED AN IMPORTANT THREAD WHY CAN'T I DOWNLOAD STUFF FROM DESUARCHIVE PAGES EVEN IF I IMPORT AS SIMPLE DOWNLOADER OR URL

okay, so. i thought this was originally because of my db being broken, but after restoring a db backup from a month ago and it still happens after that, i'm just going to assume it's a bug.

whenever i middle-click on a selection tag on a favorite search files page (as in, pages that have favorite searches loaded into them), i get an error that says 'OperationalError: no such table: external_caches.specific_current_mappings_cache_7_5' and nothing shows up in the new page. i looked in the cache db and the current mappings cache only goes up to 4, so i have no clue what's going on here. any ideas?

(i should also clarify: this ONLY happens when middle-clicking a tag on a favorite searches page. on other file pages this function works as normal)

I had a great week. The hydrus client can now have a system tray icon–to which it can also minimise or close–framerate and 'number of frames' are now both searchable and sortable, and I was able to clear out a bunch of old bugs, including the issue where tag autocompletes would sometimes not reset back to system predicates properly.

The release should be as normal tomorrow.

>>13856

Thanks, should be fixed for tomorrow.

>>13863

Sorry for this problem, should be fixed in 391 later today!

>>13860

I'm afraid I don't know anything about this problem. If you have a parser for the site that seems to work, could it be a User-Agent issue, as per the discussion here >>13826 ?

>>13813

Thank you, based dev, for your hard work.

I got a question though- what happens to the existing e621 downloader I might have? Should I get rid of it before updating?

>>13816

Thank you for this report. Is that in the manage tags dialog? Can you say more how that was related to drag and drop import, was this adding tags to files that had come in via drag and drop?

Was that two-button dialog about the same size as its parent window, maybe 20 pixels shy of each edge? If so, what are your 'default gravity' settings under options->gui->regular_dialog entry? Is it (-1,-1), or something else? Have you seen this sort of supergrowth with the file delete yes/no dialog, or was this a one-off?

>>13819

If you have not imported any custom user-made e621 parsers to your client before, it should all update completely automatically, simply overwriting the defaults you already have with the updated defaults.

If you have a more complicated situation (you may see a situation like 'e621 file page (2)'), it may all line up right or may need some massaging under the network->manage downloader definitions dialogs. The easy fix there is just to delete everything in the gallery_url_generator, url_class, and parser 'manage' dialogs related to e621 and use the 'add defaults' buttons to start afresh with just one thing for the client to select for e621.

Let me know if you need any help!

>>13824

>Thank you for this report. Is that in the manage tags dialog? Can you say more how that was related to drag and drop import, was this adding tags to files that had come in via drag and drop?

Yes on both counts. I dodn't know if that's necessarily a cause, it's just that I didn't do anything else different from usual.

I had a good week mostly cleaning code. I also fixed several bugs, including some tag autocomplete issues and the problem with potential duplicate pairs sometimes being queued up between files that are already set 'not related'.

The release should be as normal tomorrow.

BUG: With the Fusion GUI style, the "collections" drop down menu (under sort by) doesn't have check-boxes.

I've had the feeling the duplicate system is broken for a while now, so I decided to do some testing.

I created a new database. Took an image and made 3 alts of it by drawing random lines and changing colors. Imported the 4 images in the empty database.

Test: On the duplicate page I did a search at distance 0. Went though all the dupes and picked "Not related". Increased distance by 2. Repeat.

Result: Hydrus keeps asking me about the images over and over even though I previously told it they are "Not related".

Test: After reaching search distance 16. Pick "reset potential duplicates". Start over at search distance 0. Repeat previous test.

Result: Hydrus will ask about the same images over again.

Am I misunderstanding what "Not related" does? Does it not mean "these are false positives, don't ask me about this pair again"? If that's the case this is bugged. I have had issues with this for a long while in my main database. The "same quality" or "alternates" option has no problem like this.

>>13780

Thanks m8, keep on pushing.

>>13787

Thank you for this report. I am not sure what is going on here, but I will look at it.

>>13789

And thank you for this as well. I had a report about something similar to this, particularly related to resetting potential dupes, from another user some time ago, but I just could not reproduce it or see what could be going on.

Yes, 'not related' is supposed to be 'false positive, do not ask me about them (or any cross-reference of their dupes) again'.

I will give this another look. I'll do as you did and create a fresh simple db to see if I can expose it just on a small collection of files.

Hey folks, it looks like the new e621 parser has some problems pulling md5 hashes. I am not sure why this is happening, if it was always true or due to a second recent change by e621. A new parser will roll out with 389 to fix this. I recommend you pause your e621 subs again until then!

>>13771

typo >>13671

>>13771

>I'll look into it.

I've looked into it, this actually may be pretty easy. At some point, the smartcrop rust library takes just a vector of RGB pixels and their dimensions. I can just toss out the stuff it uses before that, then I would just need the raw pixels from opencl/pil. I'll give it a shot, I may be able to gpu accelerate this with opencl as well but I'm not very hopeful about it.

>>13772

>>13773

>>13771

OK. I have it working with PIL sending the raw pixel bytes to rust's smartcrop and then in rust I have multithreading going. Except, there's a problem. Python is way too slow, specifically PIL and I'm positive opencv will be the same. It takes a second or two for a single image just to encode the pixels and then encode the bytes to send to the rust library. Doing a pure python smartcrop won't work, it's too slow. 2-3 seconds per image with pure python. It would take almost a week to generate 100,000 images. PIL/OpenCV passing in bulk to multithreaded rust would be the same.

I can get smartcropping to be fast but you've gotta send filepaths, in batches.

(forgive if this reply suddenly spams four times, I am having trouble posting)

>>13775

Thank you for these updates.

The bottleneck is the human part. It is fairly easy to find a hundred potential duplicates, but having the human user go through them currently takes several seconds per file. My top priority here is to start integrating customisable automatic decision-making rules into dupe processing, so we can quickly clear out easier cases like pixel-perfect png versions of jpegs and then slowly extend that as we add better and more confident tools to do 'yeah, this is definitely a resize' determinations. I don't want to add crop or rotation detection until we have the current queue more under control.

I can pass you raw RGB bytes, whatever is simplest on your end.

Having a multi-second conversion is a bit slow, yeah. In my experience, OpenCV is about twice as fast as PIL to load an image. It also does pixel conversion stuff all the faster, since it is jumping down to a C++ dll pretty quick, and it sometimes uses OpenCL to do GPU acceleration. I am generally confident I can load, convert, and read out raw RGB values for most images in less than a second (since it happens in hydrus all the time), but perhaps there are additional encoding concerns you need that I do not understand.

I am used to scheduling CPU-heavy jobs, however, so if we end up doing this and can get it working overall in reasonable time, say less than a second per file, I can just add this as a new 'file maintenance' job type and have the client do it in the background, one every ten seconds or so, and let clients catch up in a few months of relatively very light work. In this case, I would have no concerns integrating it as an optional thing.

>>13791

>I can pass you raw RGB bytes, whatever is simplest on your end.

PIL strictly advises against this and IIRC opencv too, that's the issue. it has to convert from the C/C++ memory into python tuples. opencv and the like are fast because they store the data in memory as C structs, do operations on it, and never have to transfer that data to python and back. Then you get another slowdown converting all these python tuples back into rust or whatever language.

Example from the PIL docs:

>Accessing individual pixels is fairly slow. If you are looping over all of the pixels in an image, there is likely a faster way using other parts of the Pillow API.

A convertion of RGB values into a C struct requires a loop over all the tuples. There might be a way to register a "c" type extension with opencv/pil as a plugin but that sounds really complicated.

Unless I'm missing something. I don't image process in python that often.

>so if we end up doing this and can get it working overall in reasonable time, say less than a second per file

one option I can try is to convert the PIL smartcrop library into opencv to see if there is a sizeable speedup. that *should* lead to a pure python library with less than a second per image. with rust + filepaths I can get that under a second easily and then multiply that by cores, you would be I/O read limited. Maybe I can speed it up with simd/opencl so you don't have to multithread.

I had a great week. As well as some small fixes and cleanup, sorting files is easier, framerate sort is added, and tag lookup has some nice logic improvements.

The release should be as normal tomorrow.

>>13713

does it have the explicit images too?

Had to use a cookie extension to get derpi to parse everything I want, but the cookie seems to run out after a few hours so I need to keep constantly refreshing it… its not bad because it gets me 50 images a page, but just an annoyance that I would go back to 15 images a pull to be rid of.

>>13716

Thank you friend, this is great. Thank you for the work. I will give these a test my end and roll them in to 387.

>>13672

win 7, your installer, current session is 1424860 weight, been going through /gif/ mass trendwatcher removing shit I don't want, so its a constant opening video, and due to sound being a primary reason im able to do this, im keep with mpv, even with crashes its so much faster then opening exturaly even if double click still did that.

for what its worth these were from the preview window not the media viewer, now that I say that when I get back to parsing gifs ill try media viewer only and see if it makes a difference, right now i'm half paying attention to news while parsing images.

>>13682

ok, had a crash in media viewer too, then shortly after a second crash.

part of me is thinking something didn't install correctly, so fingers crossed wednesdays version will fix it.

>>13686

Ok, now that endchan is back up, and because its less annoying to post there, i'll be moving back to posting there. however I have an interesting… problem?… and i'm wondering if there is a solution.

so right now with hydrus I have a threadwatcher that is 2100 watchers big, and this poses some issues with parsing, some threadwatchers only have 5 images, some have 150+

some have a good name that is easy to follow, some decided a new name scheme each fucking thing is acceptable.

some make it to competition and some struggle to get passed the 100 mark.

so lets take something like… vore seems to be a good one. there are 3 threads where its the first word, but then there is /vore/ which has 22, then there are different flavors of vore… ect ect.

now lets say I want to parse them all at once, im unable to do that because they are not in any way lined up for me to do so.

now, I will admit, since the delete tagging has become a thing, I have been going through watcher lists and I probably went through several hundred this week alone parsing every images. going forward what im going to ask for has a far lesser need or impact, but if its easy to implement it would be helpful currently.

is there a way to add an exception 'search' to watchers, where if I wrote 'vore' as a search term anywhere in its subject it has 'vore' it would show it and it exclusively? when I remove the term it would show everything again?

at the very least for me this would greatly help the parsing process and even if it took a bit to implement, I have a saved session that has a metric fuckton of watchers as well.

i'm hoping that by the end of the year with all the tools that came in I can be done with parsing old watchers.

>>13687

I agree. I think adding a text filter to watchers, downloaders, and subscription lists is a good idea, and I would already like that tech available for some other parts of the program. I need to do some research first and rejigger my list code to support a filtered view, and then I will try to get this done.

I am sure you know, but just in case you do not: you can shift/ctrl-select multiple rows in the watcher list and then right-click->show all importers' new files to do easy one-step en-masse display of imported files.

>>13628

Thank you for this report. Please let me know what your log says after a help->about call in 384 as here >>13631 .

>>13631

The search complexity doesn't appear to matter, I've tested with a number of single line searches, with wildcard or specifying a specific chapter.

The files could definitely have previously had the same chapter tag deleted.

The files have not currently any siblings for those tags, however its possible I would have had tried a chapter:* to set:* sibling in the past (didn't work ;)), I may have also tried chapter:x -> set:x.

In checking this for you, I've noticed that I now have a bunch of 'unknown tag:'s for these images now - implies maybe some kind of db corruption, and no chapter tag at all. Unfortunately I only have my 378 DB to work off of (easily) to do any testing.

* for some of these tests I need to limit the results because of the number of images/tags

From 378:

Searching:"chapter:*" - finds 2 images, notably these 2 images are actually duplicates and one is from a mislabeled set. Chapters found: 065, 076.

Searching:"chapter:076" - 1 image, single chapter found, same as in above search.

Searching:"chapter:*76" - 1 image, single chapter found, same as in above search.

Searching:"*:*65" - lots*, bunch of chapters found, includes chapter 76, but includes all the images. Probably 100's of chapters - it's matching page:*65 too obviously and it's a bit awkward to count.

Searching:"series:*" - lots*, large number of chapters found.

From 383

Searching:"chapter:*" - finds 120 images, chapter 76 from previous, retagged when I noticed.

Searching:"chapter:076" - same as above

Searching:"series:*" - seeing a lot of "unknown tag" namespaced stuff, and not specific to chapter - looking like I'll need to rollback

Unfortunate, it seems it's evolved a bit since Post too long. Click here to view the full text.

>>13633

ench chan had hardware failure and they are apparently rebuilding from a backup, but as they are small yet had a 250mb upload limit, im sure thats doing them no favors in coming back online.

for the watcher just up and dying… I didn't do an extensive test when I found it was fucked, I just noticed that after putting 5 watchers on one and 1 on another a few days later one of the watchers was still unknown, thinking I fucked up a copy paste, I looked into it, and it was still correct, I then noticed that the watchers that weren't dead were not updated at all past a point despite some of the watchers getting to 151 images.

im not going to lie, I have a metric fuck ton of watchers, probably something close to 5-6000, with nearly all of them dead and waiting to be parsed.

However there are only 38 watchers that are 'active' and among those there were only 7 new ones that were being parsed. this has not been a problem since the watchers were first updated to the new type where I tried dumping several thousand threads at once.

as for the file, im on

mpc-hc 1.9.1 - just a note if you don't know, apparently one of the original people from it is still doing updates but does not have control over the main site. there have been a few small updates that made some newer encodes play correctly.

vlc is 3.0.3, will update that and see

pot is 1.7.21126

going a bit more expansive on my video player list, mpc-qt 1808 did play the file, (mpv front end) I have no idea why this will play it if hydrus wasnt and hydrus im assuming is using a newer version of mpv then this given the front end is 9 months old from when I downloaded it and possibly older,

now, when I was initially looking at this file, hydrus was not playing it, and I tried requirement it several times, till I just said fuck it and re encoded it, apparently downloading it fromPost too long. Click here to view the full text.

>>13635

Update on this:

I updated to 384 and this is the error message "help->about" yields:

2020/02/12 19:36:08: MPV failed to import because:
2020/02/12 19:36:08: Traceback (most recent call last):
  File "include/ClientGUIMPV.py", line 21, in <module>
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "/home/hydrus/Desktop/hydrus/hydrus/venv/lib/python3.6/site-packages/PyInstaller/loader/pyimod03_importers.py", line 623, in exec_module
  File "site-packages/mpv.py", line 48, in <module>
OSError: Cannot find libmpv in the usual places. Depending on your distro, you may try installing an mpv-devel or mpv-libs package. If you have libmpv around but this script can't find it, consult the documentation for ctypes.util.find_library which this script uses to look up the library filename.

So, naturally I installed the "libmpv-dev" package and now everything works. In retrospect I should have tried that sooner. For some reason I had it in my head you were shipping your own MPV binary with Hydrus and weren't relying on the system package (as you would with windows). Probably my fault for not paying closer attention.

>>13585

I hadn't changed anything but it seems to have sorted itself out. I hadn't yet restarted the client after the initial update, but on re-opening it's working properly.

Only thing I changed were the settings for whether content in the media viewer should be resized to fit the canvas. Specifically, setting smaller than canvas to be displayed at 100% and everything larger to be resized to canvas.

>>13586

Hmm, ok. Well, I am glad it fixed itself, but I have no idea what could have done it. Please let me know if it comes back or you discover anything new about this.

My best guess is it is something like a virtual desktop or an unusual multi-monitor setup. I am confident the state of tags or the media zoom settings would not change the window frame size–the window doesn't typically care about contents, but it does care about monitor resolution and so on, so if your OS was temporarily reporting back something weird like 'monitor A has resolution (0, 0)', perhaps that was causing the dialog to panic and go as big as it could.

Questions probably for future, if it happens again:

Was the dialog simply a normal window, but maximised, or was it completely borderless fullscreen, without any frame at all? If it was a normal window, was it technically 'maximised' so the button icon in the frame up top was 'restore', or was it not maximised but was sized the same size as the screen?

>>13588

It definitely didn't have a frame. At the time, a few other windows were resized too large (like manage subscriptions) and had their buttons halfway off screen.

You may have noticed Endchan and the /hydrus/ bunker there is currently down. It seems like they have server trouble:

https://twitter.com/EndChanXYZ/status/1223397527967289344

If/when they come back up, I'll be posting there again.

I had a good week, but it was a bit light again. I have nicer volume controls for mpv, and I believe I have full mpv support for the Linux build, along with a handful of bugfixes.

The release should be as normal tomorrow.

>>13549

Maybe has something to do with this? >>13529

There's an issue in this release where media isn't being unloaded from a preview window when you switch pages. This suddenly matters more because media can make noise, so be careful about leaving videos open in a search page! It will be fixed for 382.

Also some Linux/source users accidentally have MPV turned on due to their systems having the supporting libraries. They are likely to get crashes when loading media with MPV. This will also be fixed for 382, and if you are a source user, the hotfix is already available on github–it was just a single line I shouldn't have commented out.

>>13550

>>13549

I've put out a question, hopefully there is a fix I can roll into 382: >>13559

>>13567

Unfortunately, I am told the 'no filter' search strategy no longer works, so I think your best bet now is to use Hydrus Companion to copy your web browser's logged-in derpibooru cookies across to Hydrus, and then it will (presumably?) inherit your account's filtering preferences:

https://gitgud.io/prkc/hydrus-companion

>>13551 I just did a test download, and I am afraid I get all tags ok–this sounds stupid, but can you double-check your tag import options? If it is still bad, can you do a derpibooru parser test under network->downloader definitions->manage parsers?

>>13541

>Since we will be doing more edge-touching zooms, I expect I will do something with the seek bar, maybe having it render inside the video frame and pop into view when the mouse in near it, which will give us that neater view when seeing 1080p/4k vids on 16:9 screens.

That sounds great, it has been a small annoyance as well that a video matching your screen size won't fill to the edges because of the seek bar.

>The GeForce thing

Unfortunately I haven't found a way to block the overlay in specific applications, not in the nvidia control panel nor the geforce experience application. I use other features in the overlay quite often so I'd prefer to not turn it off entirely. If you can find a fix, I'd appreciate it.

I had a good week with a couple of challenges. The MPV work was difficult, so I could not get nearly as much done as I wanted. I have a basic smooth version working for all Windows users however, and some very simple volume controls. Also a bunch of bug fixes and a significant overhaul of how filetypes are selected and managed in the client.

The release should be as normal tomorrow.

I am way behind on my messages–I apologise for the delay.

Thank you, I am glad you like hydrus!

Unfortunately, I am a complete sperg and have great difficulty working with others, so for hydrus I just work on my own and I am afraid I cannot take any PRs. Furthermore, the github is just a mirror of my home environment, so I am not logistically set up to take code that way either.

I apologise, I just don't have the kind of brain that can work in any sort of team without exploding in a drama-bomb, so I now strictly abstain. I mostly point othe programmers who would like to help at the Client API now. Great projects like Hydrus Companion are written completely by others:

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

That smartcrop looks neat though! I will check it out a bit more. If you are particularly keen on getting it into hydrus, could you research it and summarise the best way to pull the coodinates of the interesting region of the image, or how to get a pure pixel-perfect crop in memory? I am not super interested in getting a jpeg on disk if that is possible–I'll likely want to do cropping/resizing/quality stuff in my existing pipeline. I can do a PIL image, but normally I work with numpy-compatible OpenCV images internally. Just posting five lines of code would save me a bunch of time.

Also as a side note, my code is all WTFPL, so please feel free to do anything you like with it.

>>13544

Unfortunately, I could not find an obvious solution to your problem.

In the coming weeks, I will be adding more configuration to the mpv window. One part of that will be the 'vo' (I think 'video output') option. Atm I have it set to gpu-hq, but it has other options for software and opengl rendering iirc. My assumption is my attempt to say 'hardware accelerate this as much as possible' has triggered your GPU into thinking it is vidya. Once that option is available, I think your best bet here is trying some different presets and seeing what changes. I would be very interested in what you see.

>>13556

Smartcrop takes a second to compute, and the python port is even slower than the javascript one at 3s or something. You would need some sort of gpu accelerated code to get fast enough for only the fly thumbnails.

>Unfortunately, I am a complete sperg and have great difficulty working with others

Yeah, I kinda figured. I'm the same way, so. I have been dabbling with arangodb (a document + graph database with full text support) to see what it would be like to have hydrus in a different database than a relational one. By the way, you are a beast with sql. I checked out some of hydrus dbs in an sql browser and they make my head spin (just a little). Anyways, I was curious what some of the bottlenecks are when trying to scale up so I could figure a way to improve them. Here are some thoughts.

1) Counting tags is extremely slow. Precomputing these is obviously not feasible since even just the combination of say, (5000 choose 2) would be in the millions of records. It's an NP-Complete problem. There's a way around this though and that's to only precompute the supernodes, tags which take up the majority of relationships. So, maybe precomputing the counts of tags for the top 100 tags, as well as their intersections/unions. That would only net you in the hundreds of thousands of records, might be a possibility. Precomputing all tags with no search parameters would probably a good idea regardless.

2) Sending every file with its tags over the wire to then be aggregated on the client is slow. That's probably why it takes so long to load up 10,000 files on hydrus. The solution would be to send just the ids, the bare minimum extra data (like the computed title/series/chapter at the top of the thumbnail) and then compute the counts. When selecting a file you pull the tags for that file and then cache them into the client. You can also start to pull in the tags for only what is in the client viewport.

3) Grouping files by series/chapter/etc can be precomputed and saved, or computed by sqlite. Right now it needs to pull in 10000 files just to group into, say, 100 chapters. That's pretty expensive. It also makPost too long. Click here to view the full text.

>>13411

>>13412

>>13413

I believe that we need to start splitting Hydrus into sub-modules that allows people to join in on the software testing process (even if dev can't handle co-development he needs to make his work easily editable).

Here are some of my proposed names for the sub-modules (using south-only constellations)

The downloader/subs engine and external download plugin adapters - Telescopium (symbolizes file discovery)

The local tag repository manager + tag visualization adapters - Argonavis (symbolizes browsing of the files)

The image viewer + media player and external program calls - Sculptor (symbolizes the viewing of the files)

The perceptual fingerprinting + quality comparison tools - Triangulum(Australe) (symbolizes local feature networks)

The IPFS uploader and external P2P file sharing adapters - Phoenix (symbolize the rebirth of sharing)

The PTR management engine and other admin tools - Crux (symbolizes the need for moderation)

The API and Web/Mobile User Interface Engines (not official) - Octans (symbolizes 8chan and 8-booru like platforms)

The Docker sets and other system configuration file sets (not official) - Reticulum (symbolizes network management)

The Disk encryption and other security management tools (not official) - Centaurus (symbolizes security over everything)

Only constellations left: Chamaeleon, Dorado (dolphin), Musca (fly), Apus/Pavo/Tucana/Grus (birds), Eridanus (river), Indus (Amerindians)

>>13390

I am afraid I am not familiar with that system, so I can't speak too cleverly. It is basically dynamic hosting of Sad Panda content to spread out bandwidth? Unfortunately, the hydrus file repository needs some hydrus-specific access stuff to pull files, and it isn't simple to set up a web browser to see it.

However the newer Client API could do this, I think, if a wrapper/interface was written.

>>13411

Thank you for all this information.

I have wrestled with the idea of title/volume/chapter/page info for a long time. It is in the back of my head to somehow split tags in hydrus into two domains–one for search data like 'character:samus aran' and one for longer one-off descriptions like 'title:samus goes to mars'. It feels to me like descriptive data would benefit from a separate data structure than search data. My thoughts on this are incomplete.

Although I played with volume/chapter/page sorting and similar from the start of hydrus, supporting chapters and pleasant narrative viewing has never been great. For the moment, I encourage people to stick with named .cbr files or whatever and use a program like ComicRack. It just does the job better, and for these sorts of nicely named series of files, it is fine to manage them with filenames. Although having 48,900 may be stretching it!

I don't think I have time to make hydrus a really good comic reader in any short timescale, but I expect some basic cbr/cbz support will come in the next year or so, and we'll see how the upgrades that come with the media viewer for that go. Having dealt with the awkward hassle of page tags, I am not a huge fan of splitting comics up into individual pages any more, so I'd like to see how chapter/volume files goes. I'd like to generally push in the direction of something like ComicRack, with a couple of bells and whistles like bookmarks and so on.

>>13424

My thoughts are simple, I would love hydrus to handle/manage my comics but pic related on how hydrus handles images, is just not acceptable.

now, take comic rack as an example, you have essentially 3 different windows/tabs, the library, the folders, and the pages,

Library is a catch all 'I tagged shit I rated shit' amalgamation to get everything.

folders, at least for hydrus, would be the hydrus imported comics, because I don't know about anyone else, but some days I go though my folder and just look though it and notice hey, I have aiki, I liked that, let's re read, If this was just looking at hydrus imported files, that's fine too.

pages would be where a focused manga gets opened and you can see inside.

personally I have files from exhentai that all come in some form of zip, I get files from nhentai that all come in a folder, and I have files that come from other sources that also get made into various formats, the ability to tell hydrus that this zip is a chapter, this zip is a volume, or this folder is a chapter/volume then move those folders to a place thats user parseable would be needed.

now the main reason I need it to be user parseable is, see the aiki above, along with my other post, if hydrus shits the bed, gg, you are never getting user parseable files back, that 48k+ files is just the porn section of my manga,

now, I honestly don't see 'title:samus goes to mars' as a tag I could ever use. because that would also mean that every single doujin I have would also have titles, and gg on ever finding what I want again without user parsability.

Now, hydrus doesn't need to store the files as rars, it could default to folders, and tone itself down I have fiels labled along the lines of

'are you fucking kidding me how long does this shit need to be for a fiPost too long. Click here to view the full text.

>>13424

>>13435

I think what he wants is just a "collections" feature. it's an ethereal item that is just a collection of other items, and can be represented in sql with a closure table. tv shows/books/manga are really the only scenario where hierarchical data makes much sense, although genres are still a tag so..

but besides that, these are all pretty much UI discussions not data structure ones. you can model everything relationally, hierarchically (if you're insane), with a graph, etc. you can even represent a graph database inside a relational sql one, but that stuff doesn't matter to the end user. tags for everything makes sense from a cataloguing perspective, you just have to make the UI represent the data in a more user friendly way. there's probably no point separating "descriptive data" just because it feels intuitive.

the only thing that really needs to be done to solve this is just to have separate "views". a manga "view" would just hide anything that isn't series/chapter/page like you can already do now, but the big difference is that you can present it differently to the user. collections can be used to prevent database bloat, i.e. you don't need to have genre:scifi on every single page only the parent node, but again from the user's perspective it makes no difference as long as it can scale performance-wise.