stumpapp
[FEATURE] Optionally disable "Series" view or Series organization altogether per library
Hello again!
Is your feature request related to a problem?
I have my books laid out in a single flat directory on disk. Stump reads this (in Collection-priority mode) as a single large series that contains all my books - which is technically correct. Sometimes, books are just one offs and aren't apart of a larger series, and that's mostly the entirely of my collection, and I don't necessarily see the need to subdivide them into folders. Maybe that'll change in the future?
Describe the solution you'd like
The option to disable, per library, series organization altogether, or at least hide that pane from the library view (so that opening that library would jump you straight to the "Books" pane) - for my specific library (and file layout), that's the immediate view most useful to me.
Describe alternatives you've considered
The alternative here would be one series per book, but that seems a little convoluted - that's effectively a folder for a single file which (arguably) is slightly worse than what I currently have.
If anything, it would make sense for me to group my files by author, but that would mean Stump reading each author as a "series" (as in the Collection-priority example in the docs), which I suppose is ok too, but would effectively be an "Author" view.
I was a little hesitant to post this as a feature because I definitely don't want Stump to fall into the trap of supporting a bunch of exotic file layouts (as mentioned in "Alternative Options" in the Stump guide on the Libraries page) - but I think this shouldn't be seen as supporting another Series pattern, but just disabling it for a given library altogether (which actually makes Stump's job easier in a way)
I'm actually going to re-open yours and close the other since you provided much more helpful information in the description of the issue, if that's okay! I haven't had a moment to meaningfully comment, but will revisit with my thoughts when I have a little time 🙂
Alright! So, I think there are a few avenues we can take here to improve the UX for folks in a similar situation re: a flat filesystem structure and how it gets represented in Stump. I don’t have a super strong confidence as far as what might be the best long-term approach for the project, but I will put my own thoughts down and hopefully others contribute to the conversation.
The option to disable, per library, series organization altogether, or at least hide that pane from the library view
Hiding it on the UI is easy enough to do, and I’m happy to surface a setting that at least achieves that, but it does feel more like a short-term workaround for a more complicated UX problem. I'll try to slot developing that setting in for sometime after the big migration effort I've been working on.
If anything, it would make sense for me to group my files by author, but that would mean Stump reading each author as a "series"
I do want to call out that, arguably, this is the expected filesystem organization method for ebooks (/Author/(Series?)/[...Books]). I did write a really scrappy script that sorts books into folders according to their author, if you or anyone reading this ever wants to give that a shot: https://github.com/stumpapp/ebook-sorter. It was a one-off thing I made for a friend and isn't perfect.
Otherwise, I think this falls into the same category as https://github.com/stumpapp/stump/issues/288, and relates to https://github.com/stumpapp/stump/issues/254 from the discussions in that thread. The big problem is that, foundationally, Stump is built around the idea that a "series" maps to an explicit location on disk which physically groups books together. To change that, i.e. to say a series is not concretely on disk, would require a significant rework of the core logic, which I honestly don't have the energy to tackle right now since I am still actively working on an equally significant rework of the backend as part of the aforementioned migration effort.
In light of that, I think a really solid medium-term solution could just be to utilize the smart list features as more of a concrete tool throughout the rest of the app. An example could be that you could create a smart list scoped to a library that replaces the series view with a list of books grouped by author, or any other criteria you want. How does that sound?
Functionally, you're right - what I'm asking would really be akin to #288.
About the filesystem layout - I've had this discussion with myself many times - Readarr (RIP) organized files as you said - by author - but Calibre-Web preferred a flat layout (at least that's what it did when you uploaded books through it, it didn't really care about how things were organized otherwise) - and I wasn't sure which to pick as they were at odds with each other. After I stopped using Readarr, I just reverted back to a flat structure. However, I'm not married to it. When I upload books to Stump, however it wants to organize files on disk will probably be what I end up going with - if that's one folder per book, or sorted by author, I'm ok with it.
For consistency's sake movies and books are very similar - what I do with my movie collection for Plex is one folder per movie - that gives flexibility to have different file formats/metadata related to a single movie all in one place. To extend that idea to books, if I want an EPUB/MOBI/whatever version of a book, logically they can go into a single folder together. Where that folder ends up? I'm still debating that myself.
The tricky thing with your proposed layout /Author/(Series?)/[...Books] is that Stump will always conflate an Author with Series -
That can be a little confusing - an Author isn't really a Series (at least the same way Mistborn would be) - to treat them the same way makes it unclear. At the Series view (in Series-priority mode), you now have to remember "hmm - was The Final Empire apart of a series? yes! so I need to go look under Mistborn and not Sanderson, Brandon". The series view becomes cluttered with books that aren't actually apart of a series, and therefore the term "series" loses its meaning.
The way Plex does it, is you can make collections/series, but anything not in a collection/series gets ignored in the Series view. So in the above example, you'll only ever see Mistborn as that's the only defined series/collection. That makes sense, trying to shoehorn media that isn't apart of a series, into the series view, makes it a more confusing view overall.
I don't think you necessarily have to ignore the fact that a
"series" maps to an explicit location on disk which physically groups books together
that will always remain true. It's just less emphasis on a "series" as a fundamental primitive that applies to all books - because that's not always the case.
However, this is all very opinionated, and will make Stump more rigid on expected file structure, which is either a good or bad thing - the issue with my argument is that it removes the ability for users to use "Series" however they want. If people want their top level folders to be Author such that Series = Author (in either mode), right now they can do that. If they want something else (or sub-divide books however they like in series-priority mode), Stump won't stop them.
My endgame layout would be something like -
books/
├── author1/
│ └── book1/
│ ├── book1.epub
│ └── book1.mobi
├── author2/
│ ├── book2/
│ │ ├── book2.epub
│ │ └── book2.mobi
│ ├── book3/
│ │ └── book3.epub
│ └── series1/
│ ├── book4/
│ │ └── book4.epub
│ └── book5/
│ ├── book5.epub
│ └── book5.mobi
The only thing that will treated like a series will be "series1" - and you don't lose flexibility in determining the author, etc... It will make Stump's job tricky in knowing if a folder nested under an author is an "book" or a "series" - but you might be able to determine that quickly by seeing if there's any media files there ("book" folder) or if there are other folders nested below with their own books ("series" folder, which is just a collection of "book" folders) - but that opens up other corner cases such as - "how do we handle books that aren't nested in their own folder under a series?"
i.e.
│ └── series1/
│ ├── book4.epub
│ └── book5/
│ ├── book5.epub
│ └── book5.mobi
Anyway, there's no right answer to anything here (and that's what makes media management so tricky!), all of this is just food for thought I suppose.
The other thing I have to remember as well - and makes my argument even less more or less valid - is that unlike Plex - which doesn't really care about where files live/how they're organized because it has external metadata to lean on - is that with Stump, the folder structure is metadata that will change how books are presented to users - changing folder structure will change how Stump treats books and the relationships between them.
Actually - there's probably little point in supporting multiple formats for the same book. This is simpler.
books/
├── author1/
│ └── book1.epub
├── author2/
│ ├── book2.epub
│ ├── book3.epub
│ └── series1/
│ ├── book4.epub
│ └── book5.epub
EDIT - realized I also just rehashed the entirety of #254 - I should have read that first - oops (again).
EDIT - realized I also just rehashed the entirety of https://github.com/stumpapp/stump/issues/254 - I should have read that first - oops (again)
Haha you're totally good. There is a good bit of similar discussion, so I'll try to keep things a little brief, but feel free to poke me on something specific if you feel I missed anything particularly important:
The tricky thing with your proposed layout /Author/(Series?)/[...Books] is that Stump will always conflate an Author with Series
That's true, and I think that at least in part that is what inspired https://github.com/stumpapp/stump/issues/280. I definitely want to get Stump to a point where these distinctions can be made, since I myself would prefer to traverse the UI in something more like Author -> Series (if applicable) -> Book
I don't think you necessarily have to ignore the fact that a ["series" maps to an explicit location on disk which physically groups books together]
If I'm understanding your point with this section starting with the above, you're basically saying to keep the internal representation of a series to whatever but to organize the UI in a way where you can traverse through the more interpreted meaning of "series"? Like being able to do Author -> Series (if applicable) -> Book on the UI? If so, I don't disagree. That is basically what I was trying to convey with:
I think a really solid medium-term solution could just be to utilize the smart list features as more of a concrete tool throughout the rest of the app. An example could be that you could create a smart list scoped to a library that replaces the series view with a list of books grouped by author, or any other criteria you want
I think a lot of what you mention after that brought you full circle to, at least in my head, the crux of the problem:
Anyway, there's no right answer to anything here (and that's what makes media management so tricky!)
This is a bit of a haunting problem for sure! You basically have a variety of formats which organize and describe themselves differently that needs to be crammed into the same system. A very fun problem lol
Actually - there's probably little point in supporting multiple formats for the same book
The multiple formats feature request was for folks that collect different editions, I personally see value in it for that but more importantly for me would be if audiobook support is every seriously considered.
I agree with every point you made - and most of what was discussed in #254 -
If I'm understanding your point with this section starting with the above, you're basically saying to keep the internal representation of a series to whatever but to organize the UI in a way where you can traverse through the more interpreted meaning of "series"? Like being able to do Author -> Series (if applicable) -> Book on the UI? If so, I don't disagree. That is basically what I was trying to convey with...
Yeah - you're spot on - it's loosening the rigidity of the "Series" label and letting that internal representation flex a little bit to whatever the user wants - #280 would be spot on - if the higher level series could actually represent "Author" and then any nested series are treated like "Series" - that's exactly what I guess would work + users will have the flexibility to nest series in series - series all the way down!
I will also mention that Stump should (probably) be opinionated on how files are laid out on disk (or at least have guardrails), not only for metadata, but also because it will determine how it will organize uploaded books on disk. I've used other apps that were excellent at finding media files on disk, no matter the folder/file structure, but when it came time for them to handle uploading media, they weren't great (through no fault of their own) at determining where those files should live. That's what I think makes Stump (and Audiobookshelf and Calibre-Web) different than Plex - they also have to manage uploads of media - and have to (ideally) organize files the way their users would expect. It's a double-sided problem.
For me there is no series for the "Moby-Dick", so when I go to series view I expect not to find it there. Some kind of ui checkbox(do not create/show series for books without series), that is respected by apps will totally work for me.
P.S. Komga creates series per every "oneshot", so I ended with 200 additional series with 1 book in it, that rendered this view completely unusable for me, especially in opds
I had another thought related to this I mentioned briefly in https://github.com/stumpapp/stump/discussions/736#discussioncomment-14256730:
...the best move [to support this feature request] might be to introduce some kind of semantic split between ebooks and other (e.g., comics, manga, etc) that presents books by author then series within a library
How does that sound? The way I imagine it would be to specify during creation whether a library is for "Books" or "Comics" (whatever the language might be) in order to make more opinionated interpretations of the UI (e.g., present authors -> author series -> books).
This wouldn't affect the scanner or how books are stored in the filesystem, I guess it would bank on rich-enough metadata to organize things for you
I think that's a good way to achieve a solution - I agree the language might be a little tricky - there are plenty of books that make sense in a Series view, and probably some comics that don't.
Would you see that as being able to be toggled on/off after library creation (just in case someone changes their mind, or the nature of their library changes in one way or the other)?
To your last point, I think that's fine. The only metadata I really rely on for organization is Author. I haven't yet seen how Stump would handle a book with multiple authors (maybe some of whom have their own individual books) - but that's a different problem.