-
-
Notifications
You must be signed in to change notification settings - Fork 70
[PoC][WiP]Feat/new media types #403
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ated config and scheduler to accommodate music module. Added music related files and directories.
…d removed the string forward reference + deferred import. FastAPI can now resolve the return type at startup.
…. Added music section to nav drawer
…s, and torrents. Also added download dialogs for albums and requests. Updated API types and package-lock.json accordingly.
|
This PR relates to #22. Phase 2 will extend further to add ebooks and audiobooks should the maintainer deem it worth continuing |
…ail with a 500 due to missing dot
…k media type to config and api types. also added some basic styling for the new media type.
|
@maxdorninger is this something you would like me to continue with? |
|
Hi @JTCorrin, I very much appreciate your efforts, but I think that it would be better if this were revisited again in a few months or so. Mostly because currently the architecture of MM is quite bad and needs much refactoring. I'm currently focusing on making TV/Movie good and maybe then the scope of the project can be increased. |
|
Hey @maxdorninger no problem at all. I understand - I wanted to get it working for me in any case. If anyone stumbles on this and wants an app that covers all media types, get in touch with me. |


This branch adds music management as a new media type to MediaManager, extending the existing TV and movie management capabilities. It follows the same architectural patterns (layered backend modules, SvelteKit frontend routes, metadata provider abstraction) and integrates with the existing indexer, torrent, and notification infrastructure.
This is a proof of concept and work in progress, published at this point to allow the maintainer adequate time to review what will be a large PR.
Claude Opus 4.6 has done a lot of the heavy lifting here, with me directing, testing and adjusting where I thought it would be necessary - for example the backend cache for musicbrainz api calls. Musicbrainz enforce a 1 request per second limit - cover art requires an extra API round-trip per artist (browse release groups → construct Cover Art Archive URL), making aggressive caching and capped lookups per request necessary to avoid blocking the response for 25+ seconds on the trending/recommended artists page.
Screenshots: