hydrus
hydrus copied to clipboard
hydrusnetwork
Comic support
From https://github.com/CuddleBear92/Hydrus-Presets-and-Scripts/issues/70 (this is currently not actionable and needs to be refined to have a list of things HyDev can actually work on, probably in the form of several issues):
This will list the needs of features Hydrus needs to replace other Comic Programs and the need of mobile apps might have.
Programs to replace:
- ComicRack for managing (Hydrus got most of this down outside of Comic Issue metadata)
- HDoujin Downloader Downloads and Scrapes the data and files needed, This is mostly here outside of again Issue metadata handling. More sites to support. (look into the program for something to use)
- Ubooquity for web-hosting for any device, Streaming or Downloading issues across the web.
- ComicVineScraper to scrape metadata from a larger database. Mangaupdates also needs to be looked at among others.
- LANraragi, webhost/reader/metadatascaper.
Needs:
- Handling pages individually as virtual groups (issues and volumes)
- Allowing groups to be nested, like individual issues being a part of a larger TPB (trade paper back)
- Extracting files and metadata to individual files for maximum fluidity. (for virtual groups)
- Exporting out to archives with embedded metadata (like a final .cbz with ComicRack xml)
- Exporting the common standards of metadata, ComicRack/ComicLover/ComicBookInfo.
- Exporting into an effective modern image format like WebP to save space on mobile devices on the move.
- Scraping of metadata sites like ComicVine or MangaUpdates
- Comic/Manga repo to not clutter the tag repo too much. Containing most metadata and metadata source urls.
- If metadata statements for missing data on the metadata sites. (Esp for imprints)
- Dedicated comics folder to not use the client_files folders, balances the same way for another path.
Web Server: Replacing Ubooquity
- Streaming and downloading files from the server on local and external networks.
- Stream-able on any browser.
- Downloads exported archives with embedded metadata to be used locally in local apps and programs.
- Searchable by most common metadata fields if not all.
- Editable in WebUI with the option to delete files and issues (cleanup blank pages or ads that might not be wanted)
- Metadata display option, allowing for the details the user wants or needs.
- OPDS support. This would enable many apps and clients being able to read and stream out of the box in theory.
Scraping: ComicVine API or MangaUpdates
- Pulls data for the issue, volume and series from the sites.
- Links of scrape saved for easy updating of the item.
- Cover image recognition for a semi-automatic confirmation of a match.
- A way to easily handle issues inside collections, this is not hosted on the ComicVine API but instead just listed in the wiki entry. (maybe scrape and parse somehow?)
- Fakku scraper maybe?
Others:
- Importing from a HappyPanda Database.
- Importing from a HDoujinDownloader Database.
- Importing from a ComicRack Database. (xml files should cover most of this though)
Maybe TachiYomi is an interesting app/piece of software to draw further inspiration from, especially its extendibility options through independently updated and managed plugins
@ShadowJonathan I can already think of a pathway. Tachiyomi <=> LANraragi <=> Hydrus Since we have LANraragi's dev @Difegue supporting our project, it would be possible to bring it all together. If using LANraragi as an intermediate is too convoluted, at least it is possible to check Tachiyomi's API through it. (Komga + Tachiyomi also works, but it would be hard to get in contact with them, besides https://github.com/gotson/komga/issues/7) (also discussions of https://github.com/happypandax/happypandax and https://github.com/hkalexling/Mango is welcomed)
Also, as a side note, I think that there are "universal Comic Downloaders" out there.
- https://github.com/manga-py/manga-py
- https://github.com/manga-download/hakuneko
- https://github.com/eight04/ComicCrawler
- https://github.com/riderkick/FMD
And with the first link, https://github.com/manga-py/manga-py/issues/328
I wouldn't mind doing a collab with Hydrus, but I feel this issue is more for people who want everything integrated into Hydrus itself. Not sure what I could add!
(As a shameless plug, LRR already handles a fair amount of the bulletpoints of this issue so I wouldn't personally use comic support in Hydrus if it came to fruition.)
Some people have a fetish for making one thing do everything, don't kinkshame. And here Ren goes again, pinging random-ish people for "cooperation" with dev despite knowing he don't like working with other people.
LANraragi support with api cross talk could be interesting. hmm Not sure how one would do it perfectly really. Import from Hydrus into Lanraragi maybe. or allow importing of comics after scraping. Both of those prob duplicate the data though. Fine in some cases but not fine for large collections. Hard to say how that would work well together really.
EDIT: there is a point here with Lanraragi here aswell, would those users use Hydrus if they already used the other? hard to say. hmm Maybe if Hydrus was the database and Lanraragi where to just host the web stuff.
Also to note, much of the reason we have so many things on the OP here is cause Hydrus moves and names all files after its hash value and more.
Much of these issues could be worked around with a dedicated Comics directory that doesnt use the normal Hydrus rules. But this isnt the best way at all. But it would make it easier to use say Ubooquity and ComicRack with it.
If Hydrus itself didnt change as a whole how the files needs to be handled. Then i personally atleast wouldnt want to have it replace multiple pieces of software.
But in short, virtual linking+webhost/reader+scraping of databases like ComicVine and others. That is what is wanted here i think.
We need the loose files to keep the other functions of Hydrus working. Like per page duplicate matching and individual tags per page. But comics itself, virtual or not should have their own metadata aswell. Maybe it will be a bit like tag siblings where the tags arnt really there on the page itself but is mirrored from the comic parents. I think that makes the most sense for comicwide tags and metadata atleast. That way you can still add tags manually to the pages or maybe even remove/blacklist it from the page. hmm hard to say, the sibling idea sure sounds like how i want it.
Firmer thoughts on Lanraragi intergration: What could happen is that Hydrus host its files in its own system but with the help of the ClientAPI it can share the path or a relative path related to Lanraragi while also having the option to pull any tags Hydrus might have.
Everything imported into Lanraragi would still be saved on its own database so it will always work without the need of Hydrus after the fact.
Example usecase: Hydrus user has files hosted on a server/nas with the client_files or server_files on the network. Lanraragi got access to these folders and Hydrus can have a prefix with a relative path for Lanraragi. (or set Hydrus path to Lanraragi, might be easier that way)
Now the question here is if Lanraragi suppoirts loose files as each page would be mapped this way which might be totally different from what that is used too.
If that is all good then its all about the path Hydrus gives and its tags. Lanraragi could also just be aware of the Hydrus folder and find the files itself with the hash value Hydrus gives it.
Doing something like this will allow both databases to merge, but would it be messy with deletions for example? Hydrus dupe actions might have to give out new hashes over the api if the file is replaced by a better version.
One of the optimal key design of Hydrus+Comics would be the ability to tag images and collections of images (comics) at the same time. If this design issue can be done it opens up new ideas for audio vs albums and other use cases.
But comics itself, virtual or not should have their own metadata aswell. Maybe it will be a bit like tag siblings where the tags arnt really there on the page itself but is mirrored from the comic parents. I think that makes the most sense for comicwide tags and metadata atleast. That way you can still add tags manually to the pages or maybe even remove/blacklist it from the page. hmm hard to say, the sibling idea sure sounds like how i want it.
It seems that the main problem is that LRR does not support "virtual links" (hash change while structure/metadata stays) while Hydrus can have such a feature. If LRR does store the original file path, then routine updates would be necessary.
Everything imported into Lanraragi would still be saved on its own database so it will always work without the need of Hydrus after the fact. Now the question here is if Lanraragi suppoirts loose files as each page would be mapped this way which might be totally different from what that is used too.
If you guys can remake Comicrack within Hydrus, you will make a LOT of people VERY VERY happy! Ever since Cyolito disappeared into the setting sun, we've been looking for an alternative. Comic Rack works GREAT!, but we're worried that one day it will quit working, and that will the end of it. One request I have, if you manage to clone it in Hydrus ( and please make ALL the features it has in it ), please give us the ability to have stacks within stacks. For instance, we can have a stack of kids comics, then under that they separate into stacks of separate titles, then under that into stacks of different publishers, and then under that into separate individual issues. Currently we can have only one stack in Comic Rack. That has been the driving issue in Comic Rack for years now. Cyolito claimed he couldn't do it because he had programmed himself into a corner. Thanks!
