mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Add music media type (for media that does not need progress tracking) #621
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#621
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Eftimin70 on GitHub (Sep 3, 2022).
Describe the feature/enhancement
Add possibility to disable the resume feature on library level.
Background:
As stated in an earlier bug report I still have problems with erratic behaviour of the resume feature on parts of my audiobooks. The problems appear with my shorter audiobooks - in German "Hörspiele" (radio plays) and I don't have issues with my longer audiobooks - in German "Hörbücher".
I have two libraries, one for my long audiobooks and one for my short audiobooks (radio plays). Since the resume feature in my eyes is only useful for the long audiobooks and more confusing than helping with radio plays it would be very useful if I could disable the resume feature for the latter.
@advplyr commented on GitHub (Sep 3, 2022):
I'm not sure what you mean by the resume feature. What is the earlier bug report you are referring to?
@Eftimin70 commented on GitHub (Sep 3, 2022):
Hi, with "resume" I mean the saving of the listening progress and the possibility to continue listening to an audiobook from where I left off. The bug report I am referring to is #644 where I have problems with completed audiobooks not correctly restarting from the beginning. If the progress determination and the features surrounding it could be disabled for my radio plays (e.g. through a switch on the library level) I would be more than happy.
@advplyr commented on GitHub (Sep 3, 2022):
Are you saying you don't want listening progress to be saved at all for certain libraries?
@Eftimin70 commented on GitHub (Sep 3, 2022):
Yes, exactly. Might seem radical, but would be very useful for "Hörspiele" (radio plays). Their length is comparable to music albums and are usually heard in one piece.
@advplyr commented on GitHub (Sep 3, 2022):
That makes more sense. I think the better solution for this is going to be adding another media type.
Right now we just have 2 media types, books and podcasts, but this was setup so that we can add more media types in the future.
I'm not very familiar with radio plays but aren't there some where you would want to keep the progress?
@Eftimin70 commented on GitHub (Sep 3, 2022):
Yes, there are longer radio plays where the progress could be useful, but at least in my library they are the exception.
A new media type would be a good solution. But if I understand the current functionality correctly you can only choose one media type per library thus it being similar to a switch on the library level. Being able to add more the one media type per library, each of them having their own paths could be a solution. So one single library could have audiobooks with and without progress functionality.
@skyzuma commented on GitHub (Sep 3, 2022):
"but aren't there some where you would want to keep the progress?"
definitively yes > one example: The Waringham Chronicles
@advplyr commented on GitHub (Sep 3, 2022):
It is similar to a switch on the library settings but it doesn't make sense to disable progress on a book or podcast library. That is what most people want audiobookshelf for.
It only makes sense if you are adding a different media type which is why I think it would be better handled by supporting a different media type.
In this case I think a music media type is where this would go.
@Eftimin70 commented on GitHub (Sep 3, 2022):
Ah, sounds good, this should work perfectly for my case.
@springsunx commented on GitHub (Nov 15, 2022):
Add music media type, I also think it's a good idea. I hope it can be realized as soon as possible. Make it look more like a music player. Like random play, loop play, single loop, etc.
@therecluse26 commented on GitHub (Nov 22, 2022):
+1, adding a music type would make this an absolute killer. I imagine it wouldn't be too terribly difficult to implement on top of existing functionality, you'd just need the ability to parse music-specific metadata from files/folders and then remove progress tracking for that media type. Also, shout out to the lib/ancap that runs this. Amazing work!
@jnbht commented on GitHub (Nov 18, 2023):
Are there any Updates on this? Would love to have a Third Music type 😃
@geoah commented on GitHub (Oct 17, 2024):
Hey @advplyr, I was interested in understanding the effort in adding music to audiobook shelf and bumped into this issue and your groundwork commit around music (https://github.com/advplyr/audiobookshelf/commit/b884f8fe1165a0c3631da2465c1863d1338811f6) so thought I'd ask if there were specific reasons your attempt didn't continue/conclude, or if it was just lack of interest/time.
If there were specific reasons, could you please elaborate a bit on what they may have been (if you even recall as it's been close to 2 years at this point) so I can better understand the task? :)
Thank you very much for all your hard work on this project. ❤️
@advplyr commented on GitHub (Oct 17, 2024):
Hey, last year the database was changed from a file-based JSON database to sqlite. Mapping the object data model onto a relational data model was a major change. When doing that data model switch I only brought over books and podcasts. At this point we still have a long way to go before we are fully switched to the relational data model and adding on another media type would further complicate the efforts.
Users with large collections are still having a poor experience in terms of performance with the media types we currently support. Once we get books and podcasts working well we can look at other media types.
@sallymanda commented on GitHub (Feb 9, 2025):
Looking forward to music type! It will be a game changer!
@Vinnecent commented on GitHub (Oct 1, 2025):
The music media type would be huge for me as well :D