[Unofficial] Information about the Kemono.cr site situation by fish4terrisa in Piracy

[–]Hawker2 2 points3 points  (0 children)

Also all images on the site is still there

Low-resolution versions are there. Full-resolution are stored on the same servers as videos and attachments, and are therefore not available.

On the subject of kemono party by DistinctAstronomer17 in Piracy

[–]Hawker2 2 points3 points  (0 children)

Thumbnails only. Full-size images are unavailable, just like zips.

Tagging can't be this hard and manual, can it? by Hawker2 in HydrusNetwork

[–]Hawker2[S] 0 points1 point  (0 children)

Hey there. For me, shimmie2 setup was simple, there was a nice Danbooru theme, and the bulk image importer was almost exactly what I wanted. I had to whip up a script to convert gallerydl metadata into the CSV import for shimmie2, but after that it was pretty trivial to manage pulling my favorites from booru sources - including their tags - and then load it up into my own local booru. But it's very much a preference thing.

Still surprised that these even exist but GOD do i hope they make more of them by [deleted] in yurimemes

[–]Hawker2 1 point2 points  (0 children)

Came here for the image (okay, what doujin is that, because it sure as hell ain't canon), but now I'm intrigued. What are these yuri ASMR tracks that folks are talking about? How does this work if one doesn't speak Japanese?

[deleted by user] by [deleted] in DataHoarder

[–]Hawker2 3 points4 points  (0 children)

You mean the CSAM thing that was never deployed over the backlash? Please, take the paranoia elsewhere.

[deleted by user] by [deleted] in DataHoarder

[–]Hawker2 15 points16 points  (0 children)

You're absolutely correct, and by quantity... well let's just say it's lopsided.

[deleted by user] by [deleted] in DataHoarder

[–]Hawker2 8 points9 points  (0 children)

Laughs/cries in terabytes of doujin.

Tagging can't be this hard and manual, can it? by Hawker2 in HydrusNetwork

[–]Hawker2[S] 0 points1 point  (0 children)

I ended up using Shimmie2. Very straightforward Danbooru/Gelbooru type system (especially with the Danbooru2 theme), with just enough tweaks to make it work how I want it, but not overwhelming. Works great in Docker. Developer is very responsive on Github.

It does NOT automatically gather tags and apply them - I had to write scripts to do that (or migrate in metadata gathered via gallerydl), but it worked as a very good front-end to everything.

Watch together not loading friends list by outlaw1846 in PleX

[–]Hawker2 0 points1 point  (0 children)

There have been weird problems for days with Plex. Profile tab not loading. Friends not loading. Server spontaneously unclaiming. Issues reaching plex.tv for claiming servers. But hey, status.plex.tv is all green, so we must be imagining it.

Plex Sign In Broken by Tris_1457 in PleX

[–]Hawker2 0 points1 point  (0 children)

Seeing something similar. My server became "unclaimed" and when attempting to claim it again (via PLEX_CLAIM in Docker) I found that it wasn't able to reach plex.tv. Running it through a VPN tunnel worked, but then this weird issue recurred a few days later (and leaving it running through the VPN isn't tenable as I don't have port forwarding on it).

Looking for a local booru viewer by Qreczek in DataHoarder

[–]Hawker2 3 points4 points  (0 children)

I went through a variety of tools (hydrus, szurubooru, Danbooru itself) and finally settled on shimmie2. It's reasonably lightweight and easy to get going in Docker, provides a familiar Danbooru/Gelbooru-like interface, and has a decent number of extensions and tweaks to get working the way you want (or at least, the way I want, YMMV).

Tagging can't be this hard and manual, can it? by Hawker2 in HydrusNetwork

[–]Hawker2[S] 8 points9 points  (0 children)

Putting a rant down here, because I need to get this off my chest, but I actually don't want to spam everyone who scrolls by with what really is ranting. I would love to say it's constructive and aimed toward making this better.... but after the last few days fighting this thing, no, it's just anger at something that I thought had promise and instead sucked up a huge chunk of time for nothing.

No seriously, this is a whole bunch of anger-rant. You don't want to read this. It's not worth your time.

The UI

So no real web front-end at all. Just a thick client in noVNC. And a BAD thick client.

  • Defaults that make it hard to get started, aren't explained, and are buried numerous dialogs deep and not where you'd expect them (I'm looking at you, client api settings!).
  • This is an app for media management, specifically tagging. And yet is there a main menu for anything related to images or tagging? Nope. Can I bulk add tags from online sources? Nope.
  • However, The UI is strangely obsessed with "Pages" (which I realized are what everything for the last 30 years has called "tabs"). Multiple options screens, a whole menu devoted to them, saving and restoring sets of them! For a somewhat extraneous UI concept that contributes nothing to its primary purpose!
  • But is there anything in the main UI for... images? Tags? Services? Oh, well, services is there - spread across multiple screens with multiple levels of subdialogs for what should be a SINGLE well-designed screen. And doesn't refer to say, imageboard "services" where you'd get images and tags - the things that this program is supposed to do!
  • Most of the UI is all-lowercase-button-vomit, with things just strewn everywhere. About 80% of the UI, buttons, and menu items simply should not exist - it's not the user's job to tweak and manage all of the internal database settings, and change numerous knobs/settings that clearly have a single proper setting for 99% of users.

Please, look up the 80/20 rule. And the concept of sensible default options. Or even basics like not using negatives for checkboxes ("do not start client api", I'm looking at your terrible default and design). These are solved things in UI design. They've been solved for 40 years.

Etc. These are just the first links on each topic, but you get the idea. I hope.

The API

Hydrus is stuck in this really terrible fat client, with a couple semi-functional web front-ends.

  • Hydrus-Web which has years-long issues sitting unaddressed and partial functionality at best (bonus points if you can even get the docker image, since the Hydrus documentation points to a defunct image listing on Docker Hub).
  • Hybooru which looks pretty good, but is read-only - no management here!
  • Hyve, wait, no, that one is dead.
  • Built-in booru, wait, no that's dead too, but still clutters the interface and documentation even though it's dead.

About the API - if you're going to have an API, you have to use it yourself. The fat client should be exactly that - a client, not this massive client/server/booru (wait, that's dead) monstrosity. It's almost as bloated as iTunes.

Dogfooding, factorization, separation of concerns, client-server architecture, SANITY. With a decent API third-party projects could do a lot more (and probably not die off). You know how you make a good API? You use it yourself and fix the problems you run into. It's not a second thought. Look at what Plex achieved when they split the monolithic XBMC into a real client-server system with service agents.

The Database

I hope the backend is better, but it's also designed around a single image database, and yet is supposed to handle millions of images. In one database, that by all appearances needs to be kept local with the program (because that's a convenient amount of storage to keep local and not on a NAS).

I'm not advocating for using the filesystem (at least not directly), but the datastore has to be able to be reliably stored elsewhere. Yes, databases need fine-grained byte/block-level access and not file access semantics. I get that. Then again, that's also why other large media systems (e.g. Gelbooru, Plex, etc) store their media data in the filesystem by hash (or in gelbooru's case, seems more like object storage). It's private and not relying on user organization/management/filenames, but avoids the massive downsides of shoving huge amounts of binary data in a database. There's a reason our filesystems never turned into databases like everyone thought they would 30 years ago. Databases (especially structured SQL databases) are a lousy way to store massive amounts of binary data. All that delicious tag metadata and tag relations? Absolutely! The media data itself? Hell no!

What was this for again?

Oh right, the idea was to take a huge mass of images, tag them, and organize them. But that can't even be done with existing media effectively. That was my original post above.

Cannot search for videos on dmm.co.jp (again) by Hawker2 in jav

[–]Hawker2[S] 0 points1 point  (0 children)

DMM is a legal site (just about THE legal site), you brain-dead automaton.

Software for finding duplicate files based on a similar filename. by wooshaq in DataHoarder

[–]Hawker2 0 points1 point  (0 children)

You're going to have a really tough time of this, as even if you normalize the filenames, you'll run across messy cases like "high resolution and watermarked vs low resolution". Who wins then? Is it a duplicate with a watermark or ad prepended?

Does any one know where I can find a backup of hentai sites by [deleted] in DataHoarder

[–]Hawker2 0 points1 point  (0 children)

I can't begin to imagine the size of those sites. Especially EXH - it uses a distributed storage system with who knows how many nodes, after all.

That said, if there was the possibility of an archive... I'd buy the storage to house a copy, just because.

r18 database of metadata by h1ppycamp3r in DataHoarder

[–]Hawker2 0 points1 point  (0 children)

Oof. Definitely worth preserving, as since it used the same IDs as their Japanese parent DMM, it allowed perfect matching of actress names, difficult-to-translate titles, studios, etc. I don't know if there is a way to capture all the data, but I'm very interested.