[FEATURE] Nested series

[aaronleopold]

Is your feature request related to a problem? Please describe.

Support a new library pattern that allows for generating of nested series

Additional context

See #254 (comment) for more context

[dominik-warch]

I am very interested in this feature. However, it would be nice if it could take folder structures of arbitrary depth into account. My use case includes TTRPG books, where I would need a deeper structure:

System -> Version -> Adventures -> Adventure -> files

Example:
Symbaroum -> v1 -> Adventures -> The Chronicles of the Copper Crown -> Part 1 - The Promised Land.pdf

[aaronleopold]

I am very interested in this feature. However, it would be nice if it could take folder structures of arbitrary depth into account

I'm not sure I understand the scenario you're asking about. For my own clarity, is the ask:

• Skip N levels of folders and treat the N+ level(s) as series/sub-series?
• Skip arbitrary depths of folders?
• Create a series for each depth level?
  • This is closer to my initial thoughts for this feature when I outlined it originally in another issue
• Something else?

It might be helpful to see an example of what you might expect the library to look like with your example.

Copy and paste if you'd like

ROOT
|-- Symbaroum
|   |-- v1  
|   |   |-- Adventures
|   |   |   |-- The Chronicles of the Copper Crown
|   |   |   |   |-- Part 1 - The Promised Land.pdf
|   |   |   |   |-- Part 2 - The Promised Land.pdf
|   |   |   |   |-- etc.
|   |   |-- Some Other Adventure
|   |   |   |-- Some Other Adventure.pdf
|   |   |   |-- etc.

{
  "library": {
    "name": "Symbaroum",
    "series": [
      {
        "name": "...",
        "subseries": [
          {
            "name": "..",
          },
          {
            "name": "..",
            "subseries": [
              // etc
            ]
          }
        ]
      },
    ]
  }
}

[dominik-warch]

Yes, exactly! Sorry if I have not made myself clear. I would also prefer your third - and your previously intended - variant. Deeply nested series/subseries would allow for very flexible structuring, which would stand out from the alternative solutions.

[aaronleopold]

Awesome, that works perfectly then since it aligns with my original plan 😅

I'm not sure if/how you are running Stump, but the experimental changes just landed on nightly. They'll make their way to be part of 0.0.2 once that tag is ready, but if you want to try out the refreshed designs for the file explorer on nightly it will get you really close to this ticket's functionality since you are just traversing your filesystem.

[mslmn]

Could Stump support a library pattern like this?

[aaronleopold]

Could Stump support a library pattern like this?

I'm hesitant to give a direct answer mostly because there isn't necessarily a structure that isn't supported, e.g. Stump won't reject your filesystem organization. Wrt supported patterns, I am mostly referring to how it interprets the underlying files on disk and converts them to its own internal representation for querying, accessing, etc. Even if Stump doesn't visually organize things 100% to your liking, the file explorers built into the UI exist to fill the gaps until more patterns (e.g. this issue) are supported since it isn't feasible to support all possible organization patterns.

This issue is specifically outlining an idea to break away from the flat-series mental model and allow for series to reference other series as children, similar or at least closer to how it would otherwise exist on disk. Separately, there are also thoughts/ideas/brain dumps to support things like skipping arbitrary depths, etc.

Your screenshot likely falls under the Collection-Priority pattern, assuming ~ A ~ and ~ B ~ are two separate libraries. So with all of that said, yes it should be scanned just fine using Stump. However, I want to encourage you to read through some of the examples I've put together in the documentation: https://www.stumpapp.dev/guides/basics/libraries#examples

[Gibson431]

I think this could be useful for simulating a serialized book where chapters are only released once at a time.
Integrating the API, it would be possible to track chapters as books.

Example:

ROOT
|-- Series 1
|   |-- Book 1
|   |   |-- Chapter 1.epub
|   |   |-- Chapter 2.epub
|   |-- Book 2
|   |   |-- ...
|-- Series 2
|   |-- ...

There is probably a much better way to present this style of media but this seems the closest way without adding a new type specifically for serialized novels.

The final goal would be running a scraper on a light novel site that pulls all the chapters to a book then uploads each one via the stump API.