Interfacing With Beets

[IrosTheBeggar]

I'm working on a music streaming app that can use Beets DB. To interface with beets I wrote a plugin that could read from the SQLite DB that beets generates. From here I wrote my own queries to pull information from the database.

I'm wondering if there's a better way to do this. I thought about writing my plugin so it could run beets shell commands, but this feels clunky. Is there a proper way for an program to get information from beets?

The program I'm writing uses NodeJS and can be found here

[sampsyo]

Hi! This looks like a really cool project; please count me as quite interested. I have basically two answers to your question:

• Talking directly to the SQLite database is probably the right way to do things for now. This is one of the reasons we like using SQLite: it lets other tools, written in other languages, easily access the data from beets. I agree that invoking the command line is probably too clunky.
• Our plan for this kind of situation is to use a network API. Specifically, we're working on writing AURA, a new standard API for communicating music and music metadata between tools. It's defined as an HTTP API for now, so your tool would communicate with beets by opening it in a subprocess and sending requests across a socket to it. But people have also been interested in a local Unixy variant that would work via stdin/stdout, which might be a better fit for your situation.

If you're interested in chatting more about AURA or even cooperating on the implementation, I'd definitely be down!

[IrosTheBeggar]

AURA looks like the proper way to go. I like the fact it's HTTP which makes it easy to interface with on both Windows and Linux. I checked the repository and it looks like a lot like my project at the beginning; an Express server that can parse metadata and server music files. I'm down to talk more about AURA.

For now I'll keep querying the SQLite DB directly. It's easy and it works well for what I need so there's no need to change yet

[sampsyo]

OK, cool. Yes, the reference server I wrote is similar in spirit to your server (although more primitive, obviously). In an ideal world, something like mStream would be able to forward requests to a beets instance or other AURA sever with minimal effort.

Maybe we can start by comparing notes on the APIs. I'll take a look around at how mStream works internally; I imagine there are lessons we can learn there!

[IrosTheBeggar]

Feel free to ask questions about the code. I recently added multi user support which made the database and security layers more complex. I plan on going back and improving the readability once some other big features are done ( such as album art)

[ahstro]

I'm currently in the process of abandoning Spotify in favor of self-hosting and after reading a lot the past couple of days, my utopian solution would be beets + aura server and client; I really like the modular approach of disparate tools for library management, serving, and playing.

I've started playing around with the aura reference server and writing my own client, but it'd be nice to discuss it along the way (also, I have a tendency to jump from project to project, so more interest might keep me hooked longer :sweat_smile: )

One concern/question I had was how this differs from e.g. the Subsonic API, which seems to be pretty prevalent and, from the cursory glance I've gotten, seems to work similarly too how aura would? (Although, my gut feeling tells me there are some key differences)

[sampsyo]

Awesome!! We would love to have you involved if you're excited. :tada:

I realize that this is a bit of an XKCD 927 response, but my problem with the Subsonic API is that I don't like using it. It's weirdly sprawly (there's stuff like videos and "sharing" and podcasts in there), extremely RPC-style instead of RESTful, and somewhat incompletely specified. I long for a clean, fully specified API for the sake of interoperation.

[ahstro]

Haha yeah, I imagined it was something like that, and I kinda feel the same.

So, I don't want to just barge in, but like I touched on, I'm imagining running something like beet aura to serve my beets library over an aura api that one can connect to with an aura-compatible client. beet web could run this same aura server and a web client at the same time, for easier access. Does that sound like a route worth trying? I started playing around with it a bit myself, but I'm probably going to need some help with all this Python stuff :sweat_smile:

[sampsyo]

Yes! That's more or less what I was imagining. Except that I anticipated calling it beet serve. :smiley:

[ahstro]

So, like I said, I don't know Python at all, really. Would you, or anyone else, like to work on refactor the web plugin to be compliant with aura or should I keep messing around with a "new" plugin to learn the ropes? For me to dig in and refactor feels a bit too foreign, at least without someone to bother with questions in real time..

[sampsyo]

Let's start a new plugin! I think a fresh start would be the right way to go. Want to start looking into it and validate your high-level decisions in this thread? (For example, I think starting with Flask is probably still a good idea, but let me know if you want to try something else.)

[ahstro]

Cool! I've started a tiny bit here, so I'll keep pushing stuff to that repo as I go along. The AuraPlugin is just WebPlugin, so there are only a couple of new lines.