Originally created by @cassieesposito on GitHub (Mar 20, 2022).
Is your feature request related to a problem? Please describe.
I have multiple copies of the same book read by different narrators and no way to distinguish them when using the app on either iOS or android
Describe the solution you'd like
Display metadata on book page like in web interface.
Narrator is most critical, but publication year, and genre would also be valuable.
Bonus points: settings to select what metadata is displayed on the page.
Describe alternatives you've considered
Current (terrible) workaround. If I have an idea of who the narrators are, I can filter library by narrator and get to version I want.
Originally created by @cassieesposito on GitHub (Mar 20, 2022).
### Is your feature request related to a problem? Please describe.
I have multiple copies of the same book read by different narrators and no way to distinguish them when using the app on either iOS or android
### Describe the solution you'd like
Display metadata on book page like in web interface.
Narrator is most critical, but publication year, and genre would also be valuable.
Bonus points: settings to select what metadata is displayed on the page.
### Describe alternatives you've considered
Current (terrible) workaround. If I have an idea of who the narrators are, I can filter library by narrator and get to version I want.
v2.0 that is in progress has been setup to support multiple "variants" of an audiobook to be under the same book.
The data model is setup to support that, but we haven't decided how that will be interpreted in your folder structure or how it will show in the UI.
Other media servers do this to allow for having a 720p and 1080p version, but I was thinking it would be useful to have several narrators or languages under the same book.
Maybe something like putting a [English] or [Narrator Name] at the end of 2 identical folder names would use the text in brackets as the variation name of the book. Just some initial thoughts, let me know if you have ideas on how to best implement this, and if it is a better solution for your case.
@advplyr commented on GitHub (Mar 20, 2022):
v2.0 that is in progress has been setup to support multiple "variants" of an audiobook to be under the same book.
The data model is setup to support that, but we haven't decided how that will be interpreted in your folder structure or how it will show in the UI.
Other media servers do this to allow for having a 720p and 1080p version, but I was thinking it would be useful to have several narrators or languages under the same book.
Maybe something like putting a [English] or [Narrator Name] at the end of 2 identical folder names would use the text in brackets as the variation name of the book. Just some initial thoughts, let me know if you have ideas on how to best implement this, and if it is a better solution for your case.
@cassieesposito commented on GitHub (Mar 21, 2022):
This would be an excellent solution as long as it was visible from the main page. Brackets have typically been used for quality settings, which are technically still a thing with audiobooks, though I do think audiobook enthusiasts are less likely to have multiple quality settings that movie buffs. If you did want to allow quality settings, curly braces could be available for narrator.
In keeping with more general media naming conventions, multiple languages ought to be distinguished with ISO 639 codes separated by a period right before the file extension. Ideally it woud accept both (ISO 639-1 and (ISO 639-2 or (ISO 639-3 and ISO 639-5))), since that would cover 99+% of people's first impulses around language codes. Probably ISO 639-2 is a better choice than (ISO 639-3 and ISO 639-5), but I sure wouldn't die on that hill, or take any sort of stand about it at all.
Alternatively, if we don't like curly braces: I doubt there are any narrators whose names would match the pattern [\d*kbps], so both narrator and quality could go in brackets in an arbitrary order and it wouldn't be that hard to parse.
@cassieesposito commented on GitHub (Mar 21, 2022):
This would be an excellent solution as long as it was visible from the main page. Brackets have typically been used for quality settings, which are technically still a thing with audiobooks, though I do think audiobook enthusiasts are less likely to have multiple quality settings that movie buffs. If you did want to allow quality settings, curly braces could be available for narrator.
In keeping with more general media naming conventions, multiple languages ought to be distinguished with ISO 639 codes separated by a period right before the file extension. Ideally it woud accept both (ISO 639-1 and (ISO 639-2 or (ISO 639-3 and ISO 639-5))), since that would cover 99+% of people's first impulses around language codes. Probably ISO 639-2 is a better choice than (ISO 639-3 and ISO 639-5), but I sure wouldn't die on that hill, or take any sort of stand about it at all.
So an example: https://www.audible.com/pd/Equal-Rites-Audiobook/B0032NANE0
/Terry Pratchett/Equal Rites/Whatever goes here [64kbps] {Celia Imrie}.eng.m4b
Alternatively, if we don't like curly braces: I doubt there are any narrators whose names would match the pattern \[\d*kbps\], so both narrator and quality could go in brackets in an arbitrary order and it wouldn't be that hard to parse.
Good call, I prefer the curly braces actually. I'm sure there are other use-cases for having multiple variations of the same audiobook, so the text between the curly braces would need to support any name you want to use for the variation.
From a UI perspective this wouldn't be very elegant just showing "Celia Imrie" as the variation name. We may need to look at this first from how we want the UI to look and function, then how it can be represented in the data model, and ultimately the file naming convention to best support it.
I thought other media servers haven't had the best UI/UX when it came to multiple variations. We had a designer help out with the mobile app and did a great job, hopefully we can get some help here in doing a mockup.
@advplyr commented on GitHub (Mar 21, 2022):
Good call, I prefer the curly braces actually. I'm sure there are other use-cases for having multiple variations of the same audiobook, so the text between the curly braces would need to support any name you want to use for the variation.
From a UI perspective this wouldn't be very elegant just showing "Celia Imrie" as the variation name. We may need to look at this first from how we want the UI to look and function, then how it can be represented in the data model, and ultimately the file naming convention to best support it.
I thought other media servers haven't had the best UI/UX when it came to multiple variations. We had a designer help out with the mobile app and did a great job, hopefully we can get some help here in doing a mockup.
@cassieesposito commented on GitHub (May 2, 2022):
The UI/UX I'm imagining looks a little something like:
if numberOfNarrators > 1:
makeNarratorFieldSelectable()
if currentNarratorQualityVersions > 1:
makeQualityFieldSelectable()
The upside to this is that there's no potentially confusing single "variation" field to deal with. The downside is that we need to create a strict hierarchy for variation selection. But I think that's pretty doable. My off-the-cuff-thought would be:
Language > Abridgement > Narrator > Custom Variation Field > (Filetype+Quality+Number of Files)
I can see arguments for moving Abridgement above language or Custom Variation Field Below (Filetype+Quality+Number of Files)
@cassieesposito commented on GitHub (May 2, 2022):
The UI/UX I'm imagining looks a little something like:
if numberOfNarrators > 1:
makeNarratorFieldSelectable()
if currentNarratorQualityVersions > 1:
makeQualityFieldSelectable()
The upside to this is that there's no potentially confusing single "variation" field to deal with. The downside is that we need to create a strict hierarchy for variation selection. But I think that's pretty doable. My off-the-cuff-thought would be:
Language > Abridgement > Narrator > Custom Variation Field > (Filetype+Quality+Number of Files)
I can see arguments for moving Abridgement above language or Custom Variation Field Below (Filetype+Quality+Number of Files)
@cassieesposito commented on GitHub (May 2, 2022):
I'm not totally convinced we need a custom variation field at all. If we do allow it, I think it should only be displayed if present. It's definitely for edge cases.
@cassieesposito commented on GitHub (May 2, 2022):
I'm not totally convinced we need a custom variation field at all. If we do allow it, I think it should only be displayed if present. It's definitely for edge cases.
@cassieesposito commented on GitHub (May 2, 2022):
I also think there should either be a boolean field to exclude a version from getting swallowed by the larger whole and instead make it its own book or a global setting that expands versions in to different books or collapses them in to one kind of like the "Collapse Series" checkbox works right now. Or maybe both.
@cassieesposito commented on GitHub (May 2, 2022):
I also think there should either be a boolean field to exclude a version from getting swallowed by the larger whole and instead make it its own book or a global setting that expands versions in to different books or collapses them in to one kind of like the "Collapse Series" checkbox works right now. Or maybe both.
When building out version 2 the data model had variations built-in, but I removed it after I realized it wasn't ideal. We can ignore variations for now as I think they will be handled differently as I initially thought.
@advplyr commented on GitHub (May 2, 2022):
When building out version 2 the data model had variations built-in, but I removed it after I realized it wasn't ideal. We can ignore variations for now as I think they will be handled differently as I initially thought.
@cassieesposito commented on GitHub (Jun 3, 2022):
Resolved by https://github.com/advplyr/audiobookshelf-app/commit/1c78af37fad354cf4b176557e7588137299cfdab
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @cassieesposito on GitHub (Mar 20, 2022).
Is your feature request related to a problem? Please describe.
I have multiple copies of the same book read by different narrators and no way to distinguish them when using the app on either iOS or android
Describe the solution you'd like
Display metadata on book page like in web interface.
Narrator is most critical, but publication year, and genre would also be valuable.
Bonus points: settings to select what metadata is displayed on the page.
Describe alternatives you've considered
Current (terrible) workaround. If I have an idea of who the narrators are, I can filter library by narrator and get to version I want.
@advplyr commented on GitHub (Mar 20, 2022):
v2.0 that is in progress has been setup to support multiple "variants" of an audiobook to be under the same book.
The data model is setup to support that, but we haven't decided how that will be interpreted in your folder structure or how it will show in the UI.
Other media servers do this to allow for having a 720p and 1080p version, but I was thinking it would be useful to have several narrators or languages under the same book.
Maybe something like putting a [English] or [Narrator Name] at the end of 2 identical folder names would use the text in brackets as the variation name of the book. Just some initial thoughts, let me know if you have ideas on how to best implement this, and if it is a better solution for your case.
@cassieesposito commented on GitHub (Mar 21, 2022):
This would be an excellent solution as long as it was visible from the main page. Brackets have typically been used for quality settings, which are technically still a thing with audiobooks, though I do think audiobook enthusiasts are less likely to have multiple quality settings that movie buffs. If you did want to allow quality settings, curly braces could be available for narrator.
In keeping with more general media naming conventions, multiple languages ought to be distinguished with ISO 639 codes separated by a period right before the file extension. Ideally it woud accept both (ISO 639-1 and (ISO 639-2 or (ISO 639-3 and ISO 639-5))), since that would cover 99+% of people's first impulses around language codes. Probably ISO 639-2 is a better choice than (ISO 639-3 and ISO 639-5), but I sure wouldn't die on that hill, or take any sort of stand about it at all.
So an example: https://www.audible.com/pd/Equal-Rites-Audiobook/B0032NANE0
/Terry Pratchett/Equal Rites/Whatever goes here [64kbps] {Celia Imrie}.eng.m4b
Alternatively, if we don't like curly braces: I doubt there are any narrators whose names would match the pattern [\d*kbps], so both narrator and quality could go in brackets in an arbitrary order and it wouldn't be that hard to parse.
@advplyr commented on GitHub (Mar 21, 2022):
Good call, I prefer the curly braces actually. I'm sure there are other use-cases for having multiple variations of the same audiobook, so the text between the curly braces would need to support any name you want to use for the variation.
From a UI perspective this wouldn't be very elegant just showing "Celia Imrie" as the variation name. We may need to look at this first from how we want the UI to look and function, then how it can be represented in the data model, and ultimately the file naming convention to best support it.
I thought other media servers haven't had the best UI/UX when it came to multiple variations. We had a designer help out with the mobile app and did a great job, hopefully we can get some help here in doing a mockup.
@cassieesposito commented on GitHub (May 2, 2022):
The UI/UX I'm imagining looks a little something like:
The upside to this is that there's no potentially confusing single "variation" field to deal with. The downside is that we need to create a strict hierarchy for variation selection. But I think that's pretty doable. My off-the-cuff-thought would be:
I can see arguments for moving Abridgement above language or Custom Variation Field Below (Filetype+Quality+Number of Files)
@cassieesposito commented on GitHub (May 2, 2022):
I'm not totally convinced we need a custom variation field at all. If we do allow it, I think it should only be displayed if present. It's definitely for edge cases.
@cassieesposito commented on GitHub (May 2, 2022):
I also think there should either be a boolean field to exclude a version from getting swallowed by the larger whole and instead make it its own book or a global setting that expands versions in to different books or collapses them in to one kind of like the "Collapse Series" checkbox works right now. Or maybe both.
@advplyr commented on GitHub (May 2, 2022):
When building out version 2 the data model had variations built-in, but I removed it after I realized it wasn't ideal. We can ignore variations for now as I think they will be handled differently as I initially thought.
@cassieesposito commented on GitHub (Jun 3, 2022):
Resolved by https://github.com/advplyr/audiobookshelf-app/commit/1c78af37fad354cf4b176557e7588137299cfdab