starred/audiobookshelf-advplyr

Fork 0

mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-03-02 22:46:55 -05:00

[Enhancement]: Allow for specifying Series hierarchy for complex book series #3198

New issue

Open

opened 2026-02-20 11:01:22 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 11:01:22 -05:00

Owner

Originally created by @ListerD000169 on GitHub (Jan 20, 2026).

Type of Enhancement

Server Backend/UI Frontend

Describe the Feature/Enhancement

Series expand/collapse works great with series that are no more that two levels deep (series/subseries/book x) Even with ragged hierarchies where some books belong to the base series and others to subseries below the base, the display functions well. For example, the Goodreads series specs for First Law World includes two subseries as well as four books that belong directly to First Law world. When subseries are collapsed in ABS, the shelf shows the subseries of The First Law, individual books 4-7 which do not belong to a subseries, only First Law World, followed by the Age of Madness subseries.

When then selecting one of the collapsed subseries, ABS then displays that series and the individual books, which is perfect.

However, if we get into series/subseries/subsubseries, the UI doesn't seem to know how to resolve the hierarchy. Cosmere is an example which contains nested subseries. Cosmere shows multiple subseries as expected

However, when selecting a subsubseries it displays the other series these books belong to rather than the individual books at the "bottom level" of the hierarchy.

This results in inconsistent behavior when collapsing the subseries. My suggestion would be to allow for the UI to respect hierarchies with depths greater than series/subseries so the behavior when using collapsed subseries is consistent. This could possibly be achieved in a couple of ways. One would be to infer the hierarchies based on the order in which they are entered into the metadata. For example, the first series entry would be the lowest level of the hierarchy to which the book belongs. Next would be the parent, then grandparent, etc. I would assume that the first entry consistently being the lowest level would make it easier programmatically to know when to display the individual books rather than the additional series/subseries the book also belongs to.

Alternatively, a more complicated, but probably more robust solution, would be to allow for specifying series and series level to explicitly build out the series/subseries/etc. hierarchies.

Why would this be helpful?

This would allow for more consistent navigation for more complex book series.

Future Implementation (Screenshot)

The behavior would mimic the way a series/subseries currently works, where when you click on a subseries from the series, the individual books are displayed for that subseries. It would simply follow that pattern for deeper hierarchies.

Audiobookshelf Server Version

2.31.0

Current Implementation (Screenshot)

Series

Originally created by @ListerD000169 on GitHub (Jan 20, 2026). ### Type of Enhancement Server Backend/UI Frontend ### Describe the Feature/Enhancement Series expand/collapse works great with series that are no more that two levels deep (series/subseries/book x) Even with ragged hierarchies where some books belong to the base series and others to subseries below the base, the display functions well. For example, the Goodreads series specs for First Law World includes two subseries as well as four books that belong directly to First Law world. When subseries are collapsed in ABS, the shelf shows the subseries of The First Law, individual books 4-7 which do not belong to a subseries, only First Law World, followed by the Age of Madness subseries. <img width="1724" height="1136" alt="Image" src="https://github.com/user-attachments/assets/6d339ada-c134-4ed7-b61e-923f5ae6175e" /> When then selecting one of the collapsed subseries, ABS then displays that series and the individual books, which is perfect. <img width="1729" height="564" alt="Image" src="https://github.com/user-attachments/assets/0e951098-0d16-4db8-8ab5-0dfedd505a6a" /> However, if we get into series/subseries/subsubseries, the UI doesn't seem to know how to resolve the hierarchy. Cosmere is an example which contains nested subseries. Cosmere shows multiple subseries as expected <img width="1720" height="1084" alt="Image" src="https://github.com/user-attachments/assets/ad1bd3e6-c2e9-4d8e-ac35-122e082b02a3" /> However, when selecting a subsubseries it displays the other series these books belong to rather than the individual books at the "bottom level" of the hierarchy. <img width="1746" height="645" alt="Image" src="https://github.com/user-attachments/assets/7e98c223-313e-486f-91b2-0163f75df13a" /> This results in inconsistent behavior when collapsing the subseries. My suggestion would be to allow for the UI to respect hierarchies with depths greater than series/subseries so the behavior when using collapsed subseries is consistent. This could possibly be achieved in a couple of ways. One would be to infer the hierarchies based on the order in which they are entered into the metadata. For example, the first series entry would be the lowest level of the hierarchy to which the book belongs. Next would be the parent, then grandparent, etc. I would assume that the first entry consistently being the lowest level would make it easier programmatically to know when to display the individual books rather than the additional series/subseries the book also belongs to. Alternatively, a more complicated, but probably more robust solution, would be to allow for specifying series and series level to explicitly build out the series/subseries/etc. hierarchies. ### Why would this be helpful? This would allow for more consistent navigation for more complex book series. ### Future Implementation (Screenshot) The behavior would mimic the way a series/subseries currently works, where when you click on a subseries from the series, the individual books are displayed for that subseries. It would simply follow that pattern for deeper hierarchies. ### Audiobookshelf Server Version 2.31.0 ### Current Implementation (Screenshot) Series

deekerman added the

enhancement

label

2026-02-20 11:01:22 -05:00

deekerman commented

2026-02-20 11:01:23 -05:00

Author

Owner

@nichwall commented on GitHub (Jan 20, 2026):

Duplicate of https://github.com/advplyr/audiobookshelf/issues/870

When using the "collapse sub series" option, the server is just looking for any books in the current view that are part of the same series that is not the current series and groups them. There is not a concept of the "main total series" other than everything is part of that series.

Edit to add: your metadata on the Cosmere books is likely causing them to be added to 2 separate sets of sub-series, so you'll want to check any built-in metadata on the files. By default file metadata overrides the folder structure.

@nichwall commented on GitHub (Jan 20, 2026): Duplicate of https://github.com/advplyr/audiobookshelf/issues/870 When using the "collapse sub series" option, the server is just looking for any books in the current view that are part of the same series that is not the current series and groups them. There is not a concept of the "main total series" other than everything is part of that series. Edit to add: your metadata on the Cosmere books is likely causing them to be added to 2 separate sets of sub-series, so you'll want to check any built-in metadata on the files. By default file metadata overrides the folder structure.

deekerman commented

2026-02-20 11:01:23 -05:00

Author

Owner

@ListerD000169 commented on GitHub (Jan 21, 2026):

Correct on the Cosmere books being in more than one subseries. That's pretty much the entire point. Cosmere is an example of a huge overarching series or universe containing subseries, some of which have their own subseries. Which it looks like ABS currently doesn't have a mechanism to handle.

Playing around with the folder structure also doesn't seem to resolve to the deeper structures. I created a test library and removed all metadata. ABS created the subseries for each of the bottom level folders the books were in, but did not create the parent series structure(s).

I know ABS can handle ebooks. Not sure if there's any desire to eventually handle comics/graphic novels, but those would require much more robust hierarchies than anything I've ever seen with ebooks/audiobooks. Some of those comic structures can get really crazy.

So at this point it seems that neither directory structure nor metadata supports these more complex universe/series/subseries/etc. structures.

From a data structure perspective, refactoring may be a considerable issues. It seems for a basic hierarchical structure with n levels of depth it could be handled by the series entity including a parent/child relationship, and the many-to-many relationship of books to series resolved via a bridge table (if it's not already). I'm not sure, but I thought I read somewhere that ABS uses sqlite, which I believe now supports CTEs, which would make the recursion queries at least relatively straightforward. I imagine performance over large collections could also be an issue with sqlite.

I'm not an app developer, so based on the current data structures and uses, I don't know how much effort that would be but I imagine it could be significant.

However after looking at 870 and also 1501, which is actually closer to what I'm suggesting, it looks like there may not be a desire to tackle this type of feature despite it being requested several times now.

Either way, I'd be happy to help with any data modeling if this were to be pursued at some point. I did data warehousing, ETL, data modeling, and data architecture for around 20 years, so while I'm pretty useless at front end development, I could provide a helping hand with data development or data migration areas if it would be useful. Thanks!

@ListerD000169 commented on GitHub (Jan 21, 2026): Correct on the Cosmere books being in more than one subseries. That's pretty much the entire point. Cosmere is an example of a huge overarching series or universe containing subseries, some of which have their own subseries. Which it looks like ABS currently doesn't have a mechanism to handle. Playing around with the folder structure also doesn't seem to resolve to the deeper structures. I created a test library and removed all metadata. ABS created the subseries for each of the bottom level folders the books were in, but did not create the parent series structure(s). I know ABS can handle ebooks. Not sure if there's any desire to eventually handle comics/graphic novels, but those would require much more robust hierarchies than anything I've ever seen with ebooks/audiobooks. Some of those comic structures can get really crazy. So at this point it seems that neither directory structure nor metadata supports these more complex universe/series/subseries/etc. structures. From a data structure perspective, refactoring may be a considerable issues. It seems for a basic hierarchical structure with n levels of depth it could be handled by the series entity including a parent/child relationship, and the many-to-many relationship of books to series resolved via a bridge table (if it's not already). I'm not sure, but I thought I read somewhere that ABS uses sqlite, which I believe now supports CTEs, which would make the recursion queries at least relatively straightforward. I imagine performance over large collections could also be an issue with sqlite. I'm not an app developer, so based on the current data structures and uses, I don't know how much effort that would be but I imagine it could be significant. However after looking at 870 and also 1501, which is actually closer to what I'm suggesting, it looks like there may not be a desire to tackle this type of feature despite it being requested several times now. Either way, I'd be happy to help with any data modeling if this were to be pursued at some point. I did data warehousing, ETL, data modeling, and data architecture for around 20 years, so while I'm pretty useless at front end development, I could provide a helping hand with data development or data migration areas if it would be useful. Thanks!

deekerman commented

2026-02-20 11:01:23 -05:00

Author

Owner

@nichwall commented on GitHub (Jan 21, 2026):

Correct on the Cosmere books being in more than one subseries. That's pretty much the entire point. Cosmere is an example of a huge overarching series or universe containing subseries, some of which have their own subseries. Which it looks like ABS currently doesn't have a mechanism to handle.

Yes, ABS has no concept of the overarching series like the Cosmere, Star Wars, etc. There are only series, and books can be part of multiple series.

Playing around with the folder structure also doesn't seem to resolve to the deeper structures. I created a test library and removed all metadata. ABS created the subseries for each of the bottom level folders the books were in, but did not create the parent series structure(s).

If you want more series to be included when scanning, you will want to embed this in the file metadata, which has priority over the folder structure by default.

I know ABS can handle ebooks. Not sure if there's any desire to eventually handle comics/graphic novels, but those would require much more robust hierarchies than anything I've ever seen with ebooks/audiobooks. Some of those comic structures can get really crazy.

From a data structure perspective, refactoring may be a considerable issues. It seems for a basic hierarchical structure with n levels of depth it could be handled by the series entity including a parent/child relationship, and the many-to-many relationship of books to series resolved via a bridge table (if it's not already). I'm not sure, but I thought I read somewhere that ABS uses sqlite, which I believe now supports CTEs, which would make the recursion queries at least relatively straightforward. I imagine performance over large collections could also be an issue with sqlite.

Yes, this has been discussed a lot but probably won't be supported anytime soon (if ever) due to the large amount of work to restructure everything and make it performant, especially because books can already be included in multiple series which effectively solves this issue. The simpler solution is to just allow users to hide series on the main view so they don't see the sub-series when browsing through all series.

@nichwall commented on GitHub (Jan 21, 2026): > Correct on the Cosmere books being in more than one subseries. That's pretty much the entire point. Cosmere is an example of a huge overarching series or universe containing subseries, some of which have their own subseries. Which it looks like ABS currently doesn't have a mechanism to handle. Yes, ABS has no concept of the overarching series like the Cosmere, Star Wars, etc. There are only series, and books can be part of multiple series. > Playing around with the folder structure also doesn't seem to resolve to the deeper structures. I created a test library and removed all metadata. ABS created the subseries for each of the bottom level folders the books were in, but did not create the parent series structure(s). If you want more series to be included when scanning, you will want to embed this in the file metadata, which has priority over the folder structure by default. > I know ABS can handle ebooks. Not sure if there's any desire to eventually handle comics/graphic novels, but those would require much more robust hierarchies than anything I've ever seen with ebooks/audiobooks. Some of those comic structures can get really crazy. > > From a data structure perspective, refactoring may be a considerable issues. It seems for a basic hierarchical structure with n levels of depth it could be handled by the series entity including a parent/child relationship, and the many-to-many relationship of books to series resolved via a bridge table (if it's not already). I'm not sure, but I thought I read somewhere that ABS uses sqlite, which I believe now supports CTEs, which would make the recursion queries at least relatively straightforward. I imagine performance over large collections could also be an issue with sqlite. Yes, this has been discussed a lot but probably won't be supported anytime soon (if ever) due to the large amount of work to restructure everything and make it performant, especially because books can already be included in multiple series which effectively solves this issue. The simpler solution is to just allow users to hide series on the main view so they don't see the sub-series when browsing through all series.