Hey everyone,
I’m new here! I wanted to share a music search and discovery tool for Lidarr. It plugs into Spotify, TIDAL, Deezer, Last.fm, MusicBrainz, Plex/Tautulli, Jellyfin, and even some AI recommendations.
GitHub: https://github.com/aquantumofdonuts/mixarr/releases/tag/v1.1.1
Website: https://aquantumofdonuts.github.io/mixarr/
What it does:
- Connects to Lidarr and analyzes your existing artists
- Hooks into Spotify, TIDAL, Deezer, Last.fm, MusicBrainz, Plex/Tautulli, and AI services
- Finds related/similar artists, new releases, charts, labels, playlists, etc.
- Gives you a review queue to approve or dismiss discovered artists
- Automatically adds approved artists to Lidarr with the profile you choose
- Has a universal search and discovery interface across all services
- Runs as a web app (Next.js frontend + Express backend) and plays nice with Docker
Why I built it:
I wanted one tool that I could point at my Lidarr library and get a steady stream of relevant artist recommendations.
Basically, make music discovery feel as automated and “infrastructure-y” as the rest of the *arr ecosystem.
Current status:
- Working with Lidarr + Spotify/TIDAL/Deezer/Last.fm/MusicBrainz + Plex/Tautulli
- Has subscriptions for different discovery sources (charts, playlists, related & followed artists, etc.)
- Docker-compose setup available, plus local dev if you prefer
- Early but usable; I’m actively using it myself and iterating
Hi, it might but I haven’t explored that. I’ll look into it. Would you want to roll your own SQLite, or just have that containerized instead of postgres?
SQLite doesnt require you to have any service running, the DB is just stored in a file which the program accesses through an SQLite library. I think its the best option for selfhosted software, as its very lightweight and more than performant enough for 99% of these use cases.
Performance isn’t the only advantage to a full postgres deployment. I have a central database for all of my self hosted apps which makes it really easy to back it all up.
I’ve had a lot of problems in the past from software crashes that left sqlite files in a corrupt state, backups where the sqlite file wasn’t properly closed leaving it in a weird unlockable state, transactions not completing when swap is used, etc. Besides that sqlite really doesn’t play nice with NFS, which is the basis for quite a few cloud storage providers.
“Best option” really depends on what self hosting looks like in your specific setup.
Yeah, I wasn’t trying to say SQLite is universally better. I shouldn’t have said best option, I really meant best default. I don’t think the majority of users are running a central db, most will just spin-up docker compose files for each service and end up with multiple SQL versions running.
I have had this issue, but it was always easily recoverable. I haven’t had the same issues with backups, although a lot of the software I use that’s running SQLite has a builtin backup feature, then I just backup that directory to a cloud service.
When an app is using an ORM already, I think they might as well make sure it supports both SQLite and a hosted DB like Postgres