Beets, Web UI and Web API

[Pierre Rust]

Hi everybody,


I've been working some months ago on a web interface for my music collection. It was written in python, with mutagen and levelDB for the backend (which only serves a REST-like API),  angularjs and bootstrap for the front-end (static html and css calling the API).

Since then I've discovered beets, which music management capabilities are miles ahead of what I had in my own code and what I could achieve one small pet project like mine. As a conclusion, I'm thinking on using it for the music management part of my web interface.

These are the functionalities I would like to implement eventually :

  * responsive html5 ui taht could be used on phone, tablets and desktop
  * simple browsing and search
  * filtered view
  * support for play-related meta-data : ratings, last-played, etc.
  * smart / auto playlist
  * playing files in the browser
  * playing files on a (local or remote) mpd server
  * play queue
  * downloading an album / file selection
  * import management (uploading a zip and monitoring / controlling the import process).
 
I've seen there is a web plugin, which is a good starting point for the API, and that there are several peoples working on similar ideas. So my question is : who would be interested in working on this ? I think the first step would be to define the API for simple browsing.

regards,

Pierre
 
PS : and thanks for the great works on beets, paired with mpd it should really be possible to implement the ultimate full-stack music solution :)

[Adrian Sampson]

Very cool! Yes, I think it would be great to make some ambitious plans for the web interface—and all of this sounds feasible to implement on a common music API backend.

Since this topic seems to be gaining momentum, I’ve started a new issue on the issue tracker:

https://github.com/sampsyo/beets/issues/718

That’s just a start; please feel free to add more to the discussion.

I think the best place to start would be with designing a new version of the API. The current one has some warts—a new take on the API with extensibility in mind would be ideal.

Maybe a wiki page for the new design would be the right next step?

Adrian

--
You received this message because you are subscribed to the Google Groups "beets" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beets-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Thomas]

Re: Web-UI stuff, can I throw Groove Basin into the mix (https://github.com/andrewrk/groovebasin / http://andrewkelley.me/post/quest-build-ultimate-music-player.html). I got shown this link after some amazing feedback over at What.cd when I asked for help with my MPD set up. Some kind sir pointed me in this direction and I have to be honest, it looks incredible.

It looks like a lot of hard work has gone into this project, much like Beets, a labour of love and it would be good to support it and try to join forces in some way. Of course, this is just my opinion. 

My belief is that we could harness the power of Beets to compliment a music front end like this. The beauty, in my opinion of these projects is to keep them independent but when put together, they are powerfully unbeatable.

I love what Andrew Sutherland has done with Web-PD, it looks amazing, especially the graphical feedback stuff. Maybe there's

 some way to streamline all this stuff, I'm sure.

[Michael MacLeod]

Hello Everybody,

I don't have any specific assistance I can provide, but I do have some thoughts. I've been trying to tie together various elements for years now. I've tried subsonic, beets, mt-daapd/forked-daapd, mpd, mythtv, xbmc, and probably other stuff too. Right now I've got subsonic, beets, and xbmc in the mix, plus an iTunes install that's not really tied in at all but is important since that's how the ipod gets it's act together. Not all of my stuff is running on the same system - specifically the system with the music library and beets and subsonic is a headless linux box in a closet because it's got a ton of hard drives and is loud. The media centre is running xbmc in the living room and mounts the music over the network.

All of the tools I use work well, but none of them work well together. Subsonic is great for accessing my music when I'm not home, but I can't stream from subsonic to my xbmc machine when I'm home. None of the xbmc web interfaces are as good as subsonic for music, but I do want to use xbmc for music at home since it's already wired into the receiver and the receiver it probably already on the xbmc input. It seems silly to run both mpd and xbmc on the same system and have them fight for audio playback, ditto for running subsonic from the xbmc machine and using it's jukebox mode. This is especially important when I decide I want to watch actual video on the xbmc system - having to go and find what other service is playing audio presently to kill it would be annoying, whereas right now I just select the video and the music stops. The less said about forked-daapd/mt-daapd the better at this point, so iTunes is just off on it's own.

I guess what I'm trying to get at is that whatever you guys do, please take the time to look at DLNA/UPnP/DAAP. Whatever you guys build, unless it satisfies all possible use cases, will probably be used in tandem with other projects. If you've got good DLNA/UPnP/DAAP support though, then they might actually stand a chance at working well together. And that would make me very happy.

Cheers,

Mike

[Johan Helsingius]

> I guess what I'm trying to get at is that whatever you guys do, please take the
> time to look at DLNA/UPnP/DAAP. Whatever you guys build, unless it satisfies all
> possible use cases, will probably be used in tandem with other projects. If
> you've got good DLNA/UPnP/DAAP support though, then they might actually stand a
> chance at working well together. And that would make me very happy.

While I understand why you would want DLNA support, I just wanted
to state that not all of us feel the need to support it - it is too
much of a "least common denominator" standard. I looked at moving
over to a DLNA-based system for exactly the reasons you mention,
but would have had to give up too much of the functionality of
my current squeezebox-based setup.

Julf

[Adrian Sampson]

Indeed; compatibility will be good to keep in mind, Mike. One possible approach to this that I've been tossing around is to do all the "plumbing" in this hypothetical REST API but provide adapters that translate to, e.g., the Subsonic and DLNA protocols for compatibility with existing tools. This is approximately the same strategy we took a very long time ago in building our music player to speak MPD's language so it could take advantage of the wide array of existing clients.

Inventing new "plumbing" admittedly smacks of this problem:
https://xkcd.com/927/
But is perhaps justifiable in this case because the existing protocols are all so frustrating and proprietary.

Adrian

[Pierre Rust]

Hi,

I totally agree with Julf. I have a decent knowledge of DLNA (not so much for DAAP) and I think it has two major problems : the feature set is too poor (especially on the library management side, which is beets strong point) and the vast majority of implementations available today have a very low quality level (I have half a dozen DLNA capable devices at home, which almost never work well one with another).

That said, I see two scenarios where DLNA-compatibility could be interesting :
 * a plugin that would control a DNAL MediaRender (the same way we can control a mpd daemon or any other music-playing system)

 * a plugin that would act as a DLNA MediaServer exposing the beets-managed library.

But these two use-cases are imho independent of the Web API.

Pierre

[Michael MacLeod]

Hi Pierre,

You are correct that this is all independent of the web API - I've been thinking about the web UI specifically and what functionality I would find useful in it. The use cases you describe are primarily the ones I was thinking about. Specifically, navigating a large music collection with a TV remote is kinda painful. I tend to use a tablet with the XBMC remote app or my browser to access an XBMC web UI to play music (though the XBMC web UIs universally suck). What I'd really like is to have a nice UI for music (through beets, with a decent mobile version for when viewed with a tablet or phone) that will also let me select XBMC as an output target over the local network. Of course the web UI should also let me play through the browser allowing my to listen to my music when I'm not at home. At that point you're integrated into my stereo and I can ditch subsonic and the XBMC web UIs entirely.

A module to let beets act as a DAAP server would be nice since there hasn't been a decent open source DAAP server that I can find for years. Most people in my life are running Mac with iTunes so DAAP would be useful to me.

I realize that these are all asks, and that I'm not offering to put any of my own effort in, so no one has to listen to me. But the use cases described above are where more code might make my life more convenient, and if they can get solved while you guys are putting together the web stuff for beets that would be awesome.

Thanks,

Mike

[Jonathan Fritz]

Hey all,

I'm late to the discussion, but I'd also like to throw my hat in as an interested party in this project. I've been (slowly) working on my own music streaming front-end for a couple of years now, and would love to see more momentum behind a project like this. Beets is the perfect back-end for a project like this, and I've been working on a fork of Adrian's AudioRead library for doing the conversion necessary for streaming audio.

I'll take a look at the bug and lend my hand where needed.

Jonathan

---
Jonathan Fritz
On the web: http://www.jonathanfritz.ca

[Pierre Rust]

great, good to know they are many people interested into this project :)

Pierre

[Justin Hornosty]

+1 

I'm quite interested in doing work on this. 

The major benefit of a webui would be aiding the import process which for large music collections can be quite painful. Managing the db would also be far more intuitive graphically.

[Adrian Sampson]

Awesome; it’s seeming like there’s a critical mass of people interested in hacking on the future of the web interface!

Can everyone who’s interested in participating add themselves to the relevant GitHub issue?

https://github.com/sampsyo/beets/issues/718

From there, we can start making plans and assigning tasks in smaller issues. There should be plenty of work to go around. :)

Adrian