stump
stump copied to clipboard
stumpapp
[FEATURE] Folder Structure
Is your feature request related to a problem? Please describe. My Folder structure is something like:
Library 1
|-- Author 1
| |-- Series 1
| | |-- Book 1
| | | |-- Book 1.epub
| | | |-- Cover.jpg
| | | |-- Metadata
| | |-- Book 2
| | | |-- Book 2.epub
| | | |-- Cover.jpg
| | | |-- Metadata
| |-- Series 2
| | |-- ...
|-- Author 2
| |-- ...
Library 2
|-- ...
The folder structure is used by Audiobookshelf and is pretty similar to Calibre. The problem is, that Stump reads the Series only from the the folder Structure and not the metadata, which leads either to every book being in it's on series, or the author being the series, both is not ideal.
Describe the solution you'd like Add the folder structure as a third option, or only read series from the metadata
Describe alternatives you've considered probably the easiest option would be to allow books be placed in a book-folder and the book-folder into a series-folder
The problem is, that Stump reads the Series only from the the folder Structure and not the metadata, which leads either to every book being in it's on series, or the author being the series, both is not ideal. ... Add the folder structure as a third option, or only read series from the metadata
You're correct, Stump does not currently support building a library from metadata. Rather, it is the file structure. The metadata is used afterwards, e.g. filtering. I am not necessarily opposed to adding support for the former (library from metadata), however the requirements for how it should work would need to be thoroughly laid out (namely, what does the metadata look, where is valid placement throughout the different file structures, and how should Stump reconcile parsed metadata with what it indexes on disk).
As for supporting the other file structure explicitly, I'll consider it. To be completely honest, assuming I am understanding correctly, it is almost exactly what the Collection priority pattern achieves. The only difference is that, in your case, you'd like the first child directory of the library root to be ignored. Supporting that in and of itself is not too much, but it just means supporting yet another pattern to maintain. I am currently rewriting the scanner, so I'll have a better idea towards the end of that effort what supporting that structure might look like.
As a side note, I think I'll need catchier names for these patterns because I can't think of what this proposed one would be called relative to what Stump supports today (Collection vs Series priority) 😅
Somewhat related, as well, to https://github.com/stumpapp/stump/issues/196, perhaps it would make sense down the road to just support a library pattern that supports generating of nested series. This way, you could have a library where the root level series are authors, and each author would have a sub series for each book series.
E.g. something like:
ROOT
|-- Sanderson, Brandon
| |-- Mistborn
| | |-- The Final Empire
| | |-- The Well of Ascension
| | |-- etc.
| |-- Stormlight Archive
| | |-- The Way of Kings
| | |-- Words of Radiance
| | |-- etc.
|-- Some Other Author
| |-- Some Other Series
| | |-- Some Other Book
Which would more naturally represent the data structure of a library:
{
"library": {
"series": [
{
"name": "Sanderson, Brandon",
"books": [
// All of the books in the series (author) and sub-series (actual book series)
],
"subseries": [
{
"name": "Mistborn",
"books": [
// All of the books in the sub-series (actual book series)
]
},
{
"name": "Stormlight Archive",
"books": [
// All of the books in the sub-series (actual book series)
]
}
]
},
]
}
}
That's a very large paradigm shift, though. Wanted to throw it out there.
Somewhat related, as well, to https://github.com/stumpapp/stump/issues/196
yes, that would be a similar library
This way, you could have a library where the root level series are authors, and each author would have a sub series for each book series.
A recursive library there every book is inside its own folder more would make more sense to me as it seems more future proof. if some day metadata files get implemented they can be added to the book folder instead of having another library only for metadata.
on a related note, why is one library restricted to one folder and one folder restricted to one library?
A recursive library there every book is inside its own folder more would make more sense to me as it seems more future proof
This is a prerequisite for the linked ticket (#196). The idea for that one is you can group multiple files of the same book within a single folder, e.g. a PDF and an EPUB, and Stump would recognize the different files while retaining a single media entry in the DB to group them. If it can do that, then it can recognized a folder containing parts of a book. The long word vomit I had above was just a tangent off of that idea that I thought was similar-ish.
on a related note, why is one library restricted to one folder and one folder restricted to one library?
I'm not sure what you mean. Libraries don't currently support multiple sources, if that is the question. Hypothetically it can one day be extended to support it, I imagine it like how Plex works. However, for the second part of your question, why would you want the same folder present for multiple libraries? You would have duplicated media
why would you want the same folder present for multiple libraries? You would have duplicated media
What I do with my audiobooks in audiobookshelf is, that every user has access to his personal library with a puplic and a private audiobook folder, and all public audiobook folders are in a shared library every body has access to .
So you can keep some audiobooks private and same audiobooks you can share with friends and family.
Just wanted to say that I'm interested in support for nested series. Thank you for your hard work.
I think nested series are the best way to go. I also just want to add a +1 as a user who would definitely use multiple sources for a single library.
I think nested series are the best way to go. I also just want to add a +1 as a user who would definitely use multiple sources for a single library.
I created a separate issue last week to better track the first request 🙂 I like the idea so am planning on tackling it hopefully before 0.2.0. I'll be focusing on general stability and honing the existing features for 0.1.0
As for the multiple sources, I haven't created the ticket. Feel free to create one!
I also want to say that I've been working on some usability improvements for the file explorer, extending it to be re-used for both library and series screens. Since it is just traversing the file system at the relative root, I think it is close to what nested series might look like until it gets worked. So it could be a valid alternative until that point. Currently, those changes are in experimental, but will make its way to nightly and 0.0.2 shortly after.
I wanted to throw in a +1 request for supporting imports where the series is based only on comic file metadata (internal tags firstly, then filename parsing), rather than any folder location. This would useful for folks who have meticulously tagged files that aren't organized into a particular folder structure.
Currently I think Codex is the only server app that supports this, but it would be nice to have more options.
(As a experiment, though, I have a test script to build a folder tree based on publisher/series tags, and populate with symlinks to the actual file locations. It's functional with Stump, but less than ideal. )
I've created a separate issue for folks to better track it: https://github.com/stumpapp/stump/issues/288
Currently I think Codex is the only server app that supports this, but it would be nice to have more options.
I thought Kavita supports metadata libraries, but I could be mistaken
Thanks for considering this!
Re: Kavita, I just had another look to be sure, and seems that it still relies on a strict folder structure: https://wiki.kavitareader.com/en/guides/managing-your-files/scanner#introduction
Komga does read metadata as well, https://komga.org/docs/guides/scan-analysis-refresh/ Has a brief rundown of what fields it expects from the metadata files it can read
Komga does read metadata as well, https://komga.org/docs/guides/scan-analysis-refresh/
Has a brief rundown of what fields it expects from the metadata files it can read
Komga does read metadata, but I don't think there exists an option to completely ignore the underlying filesystem and instead rely solely on metadata to construct the library and series (which is the ask discussed above)