Is Groove Basin a radio, a jukebox, or a personal audio player?

[yoasif]

There doesn't appear to be a mailing list for Groove Basin, which is where I'd usually put this kind of commentary, but Github issues should be ok.

While playing around with Groove Basin since I saw "My Quest to Build the Ultimate Music Player", I've run into several moments where I am confronted by Groove Basin's schizophrenia.

Hence, is Groove Basin a radio, a jukebox, or a personal audio player?

In the post @andrewrk talks about a multitude of features the ultimate music player should have, all the way up to the "PartyBeat" section, which seems to have led to the confusion I see in the application today.

Let's start with Amarok/Clementine, which we can use as an example of a personal audio player:

• it runs as an double-clickable application on a user's machine
• playback is inextricably linked to the machine that it is running on
• remote controls are available, see: Clementine Remote

and let's compare it to mpd, which is another application that was referenced in the post:

• client/server model
• the player and server are one and the same (unless using pulseaudio redirection)
• playback is inextricably linked to the machine that it is running on
• remote controls galore -- all "clients" are basically remote controls for the server/player app

Both of these players are pretty good at the single user near their audio playback hardware use-case, and MPD excels at running on devices that are very underpowered. In the most basic use-use case, both run as personal audio players.

When users add remote controls to Clementine or mpd, the application becomes a jukebox. The application runs on the "jukebox", displaying a library and play queue, and any number of users with access can control the song that is playing -- by using the Clementine remote, or an mpd client.

This sounds a lot like "PartyBeat" as well -- clients connecting to a website where they can choose the songs, with the fairly cool feature of being able to upload a new song to the jukebox. PartyBeat still had the very Jukebox-like characteristic of playing audio (making sounds) in a single location.

mpd though, has the somewhat unusual feature of being able to output to multiple locations at once -- including things like HTTP and shoutcast servers. This enables it to act like a radio.

Using mpd like a radio station, even one that a sole user controls, seems to not be a widely used function, though. I can't think of a single mpd client that actually plays music at the client-side! This is likely because they simply focus on creating a nice frontend around the mpd library and play queue, and let mpd worry about the audio output.

So while mpd can act as a radio station, it's usually used as either a personal audio player, or a jukebox.

Even in the scenario where mpd is acting as a radio station, it's likely even more unusual for a listener to be able to control the play queue, or to see the music library. I would believe it wasn't too unusual if I could find a single example of an mpd client that could also tune into the "radio" stream, without needing to open mplayer, or a separate audio player. Basically, this user doesn't exist.

But this is exactly what Groove Basin allows out of the box. Unfortunately, as an innovator in this area, the user experience is very odd.

Let's walk through a few use cases:

User with a Groove Basin library at home, who would like to listen at work.

User has set up Groove Basin on her home machine, presumably one with speakers. She connects from work and begins to play her music via the web UI "stream" function. She is wearing headphones, and is listening at full volume. Her roommate comes home early. The user's music library is on her laptop, which is playing an extremely loud (and annoying) anime soundtrack.

What's her roommate to do? Suffer through the loud, annoying soundtrack, or look for a way to mute the music? After looking for a way to disable the sound, the roommate cuts the power, interrupting her stream.

How about a more innocuous example in the same vein? User is listening at work, but has no roommates. The same album is playing, but now the neighbors are suffering through a variety of albums. The user comes back home and has fewer friends.

Here, because Groove Basin is both a radio station and a jukebox -- at the same time -- we saw adverse consequences occur because of audio playing at the jukebox end of the stream.

A group of friends are connecting to a single Groove Basin instance to share the radio experience.

A user has decided to share their entire Groove Basin library across the internet to allow his friends to both run and listen to a radio station at work.

Users connect throughout the day and listen to the radio.

One of the users has a meeting, and decides to pause the audio. The audio pauses for everyone. The user has brought his laptop into his meeting, and one of the other users on the Groove Basin station starts up a not-so-safe-for-work track (a user on the Groove Basin radio uploaded this track). The user is embarrassed, and is possibly reprimanded.

The user in this instance was unable to clearly control his listening experience -- he clicked pause/stop, and someone else was able to play music on his machine.

The radio station/receiver functionality seems to be a niche functionality that has been promoted to a core feature in Groove Basin, in ways that seem counter-intuitive and confusing.

Here is what I would envision that Groove Basin could resolve these issues:

1. Focus on the personal audio playback functionality. The use-case here is one machine and a set of speakers.
2. Remote controls are great. Let's be clear about this functionality, however. Groove Basin by default is a jukebox with remotes -- since it is mpd client compatible, there are a lot of remote controls.
3. The radio station functionality in Groove Basin is extremely confusing in the main UI. We should break out this functionality into a plugin or preference that users can disable or enable. The default option should be disabled.
4. I'm not certain that users are actually interested in radio. If anything, I would envision some Subsonic or DAAP like music sharing like iTunes or Rhythmbox have would be more interesting to users -- with functionality like last.fm scrobbling, we could even emulate the current "radio" functionality by allowing users to "follow" scrobbles from a particular user, and play that music as they play it. This allows the client user to be able to play any music they wish, but also allows them to have access to the entire music library of the user without needing to force other users (like the owner of the Groove Basin install) to listen to what a single user would like to listen to.

It seems tempting to resolve some of these issues with permissions, controls or voting mechanisms. Perhaps that is the solution if users are really interested in radio station administration. The growth of services like Spotify and Google Music indicate to me that that isn't the case -- users want large libraries to listen to, they enjoy music discovery, but they also like being able to choose what they listen to.

DAAP/subsonic like functionality, with the addition of a last/libre.fm "follow" would get Groove Basin users most of what they likely want, with none of the downside of weird UIs and none of the fights over administration of play queues.

DAAP/subsonic like functionality also gets away from problems like having to play music at the serverside, or syncing the progress bar correctly (issue #229), or encoding music that no one is listening to (#143), or the weirdness of turning on a stream on the same machine it is already outputting music to (#224).

Hope we can discuss this a bit -- libgroove seems really promising, but I think Groove Basin needs to be really top notch, even in a basic state for it to take off -- and we want it to take off, because there is a serious dearth of really high quality gapless audio players with good loudness adjustment features.

[Ichimonji10]

I think this is a valid issue. Even after reading through "My Quest to Build the Ultimate Music Player," I still wasn't sure exactly what GrooveBasin was. Indeed, I use Subsonic because it is capable of acting as a personal steaming application and/or jukebox, and it does so in a very clear way. Sure, it has a horrible UI and lacks replaygain, but it's fundamentally more understandable than GrooveBasin.

[ViktorNova]

Thank you for this very descriptive and hilarious summary, I now have a much more clear idea of what Groove Basin actually does, and it's intentions and limitations. I was looking for a modern way to share a playlist with my band mates in a common format that any computer or phone can use, privately.. looks like the search continues!

[jprjr]

After reading this and trying out Groove Basin, I thought I'd share a few thoughts.

I would kill for something akin to multi-user MPD. My SO and I have our own music libraries, and there's a decent amount of overlap - but we each have music the other can't stand (I love Reel Big Fish, she can't stand them).

Right now, we each have our own Music folder in our respective home directories, and we have our own devices which we like to listen to music on. There's a few shared devices, like a PC in the living room running XBMC.

The most ideal thing for me would be one master library of music, and to have multiple users each with their own subsets of the master library. Something we could both upload music into, maybe receive some type of notification that there's new music available and click "I want this to appear in my library". Maybe it doesn't have to be full-on libraries, but something more like each user can maintain a set of playlists. That might be better, actually - you could have shared playlists and whatnot.

I'm not gonna lie, I don't care as much about having something that actually plays the music on the system's speakers. I'd vote that should be off by default, and streaming should be on by default. I really want an easy-to-use system that organizes music, scans for replaygain, lets me make playlists, and provides streaming access - so we could both listen at work, independently of eachother, to our own music. Even cooler would be to export the music library as a filesystem (say, via WebDAV or something) for easy access with other music players. Another idea - send music out via pulseaudio or upnp or airplay or whatever - so we could each pipe our music around the house.

When I saw that "upload music" feature in Groove Basin, I immediately thought of that kind of use case. I really want something where I just lazily upload music and it gets organized, and anybody with access to the server now has access as well.

There's other media servers out there, but it seems like they're all oriented towards one person, playing on one device. The closest thing to what I'm describing seems to be Ampache - but that doesn't have the EZ-mode upload functionality. And the whole thing feels very clunky and slow compared to what I've experienced with Groove Basin.

I would love to have something that really embraces the idea of multiple users w/ multiple devices. I don't care quite as much about MPD compatibility, etc - though that's just me.

[ViktorNova]

If Groove Basin was multi user, I would kill (or at least injure) for it too! Ampache is so non-intuitive, Groove Basin definitely is the superior technology. I agree the one set of speakers thing was a surprise to me, I figured "It's web based, so it must play on the client, right?"

@jprjr - Have you checked out ownCloud? http://owncloud.org/ It kind of does what you are talking about =)

The music-specific features are not the main focus of the project, and it shows a little - like the web-based music player itself is a little clunky and it's built-in Ampache streaming feature doesn't really work (at least on my setup, but I'm running it on shared hosting-so can't complain!), BUT that being said, I use it almost exclusively for shared music, and it works great with a client-side player. It serves files using WebDAV, has multiple users with multiple levels of access, and you can mark any folder or file as shared through the web interface, or just drop stuff into your shared folder, and it instantly pops up to the people or groups you shared it with. The web interface is nice and stupid easy to use, and it has a Dropbox-like client for basically every desktop & smartphone OS! Just sayin ;)

[yoasif]

@jprjr surprises me to some degree.

The initial blog post, which I resonated with, is what led me to believe that this was a desktop music player with an odd choice of language and "client".

Some of the things that continue to confuse me are the fact that this application isn't even really a "webapp" in many ways -- it's a client/server webapp, where one runs a server on some machine (possibly not local), but where the client is both the server and web based clients.

If this app were a purely in-browser application that loaded up libgroove in the browser, and targeted Web Audio API audio, while pulling in media from a webdav source, that would make more sense to me.

Making libgroove beholden to unix-like machines for playback seems like Groove Basin doesn't really consider the web client to be a first party client for libgroove -- it's not as if libgroove is running in browser -- I'm actually curious to know whether we get the assumed benefits of libgroove when running in a browser only -- things like gapless playback. I haven't tested this, since the web browser is actually a bit of a crutch to me - I'm already running the audio engine on my Linux machine, so why should I suffer through a web browser to basically use it as a remote control?

And yes, it is a chore to use this in a web browser -- even slow native applications like quodlibet are preferable to me than using a webapp - any webapp -- my GTK themes are not respected, fonts and sizes are not what I expect, I lack basic things like drag and drop functionality (having a library doesn't preclude this option), the play/pause/next/previous buttons are not easily accessible in my panel like they are for my other Linux media players.

Does Groove Basin in the browser bring with it all of the power of libgroove? If so, I can definitely understand some of the desires posted here.

I think, though that projects like Subsonic have basically cornered the (existing) market for playback of remote audio - is this something that either of you have tried, @jprjr @ViktorNova ?

My bias is definitely to a "native" player - perhaps with an option to stream, like Clementine has -- unfortunately, it is far easier or me to mirror my library at work than it is to try to stream from my machine at home, given my slow upload access, and lack of desire to pay exorbitantly for the privilege of a higher upload speed.

[Ichimonji10]

@ViktorNova owncloud may do what @jprjr is looking for. However, it's complete overkill.

I agree that Ampache is... bad. I tried packaging the application for Arch and failed. The setup is stupidly complicated, documentation is terrible, and really nothing about it smelled of quality.

EDIT: remove flame-war material

[jprjr]

@yoasif - subsonic looks good, but I don't like their way of handling "premium" - mostly that you have to pay to disable ads. I'm fine with paying for more features, but paying to disable ads really bothers me.

@ViktorNova I've used owncloud before, but like others said, it's just not oriented towards music.

@Ichimonji10 I agree about Ampache. I was able to make a Docker image for Groove Basin in all of 30 minutes - https://index.docker.io/u/jprjr/groovebasin/ - and every single feature works, it's awesome. I've yet to get Ampache working the way I'd like it to.

I think for the single-user, desktop music library experience, it's pretty hard to top MPD w/ beets. That gets you ReplayGain scanning, something close to "Loudness Zen" (MPD has "auto" mode - which will use track gain if you're playing in random mode, album otherwise), a nice, organized filesystem, auto-tagging, auto-album art, and smart playlists.

What I'm looking for nowadays is convenience. Like I said, I want something where I (and roommates, friends, coworkers, whoever) upload music into a huge music repository, then make + share playlists, and stream to whatever. I would love to click a playlist a friend's made, download an m3u file and start playing it in my current desktop client. Or just play in my browser. Or on my phone. Or export a zip file of MP3s to shove on a USB stick and use in my car.

begin rant Have you tried using a car stereo's USB port without an iPod/iPhone? It's terrible, none of the desktop clients are any good at dealing with "take this playlist, encode FLAC to MP3, and put it on this USB stick" without jumping through some bizarre hoops (like placing a hidden file on the USB stick to make the clients treat it like a media player). I wound up writing my own set of scripts to accomplish that. end rant

Basically, I want ampache + upload + beets + replaygain/ebur128 - and I think there's a ton of use cases that are really underserved/not served at all by existing clients. Given how relatively new Groove Basin is, I'd love to see it target these kinds of multi-user, convenience-first use cases. But maybe that's just me. The Jukebox is cool, but I think it's been done to death - I'm in the market for a really cool media server.

[yoasif]

@jprjr Madsonic is a subsonic fork that removes payware hooks. I would have posted that instead, but figured there was more documentation and feature information on the subsonic site.

Like I said, I want something where I (and roommates, friends, coworkers, whoever) upload music into a huge music repository, then make + share playlists, and stream to whatever. I would love to click a playlist a friend's made, download an m3u file and start playing it in my current desktop client. Or just play in my browser. Or on my phone. Or export a zip file of MP3s to shove on a USB stick and use in my car.

I think beets is getting there, and it isn't focused on being a player (although it can play).

Look at the web plugin for beets for some of this.

I would use mpd (I already use beets), but the clients are not nearly as pleasant to use as gmusicbrowser or Rhythmbox or even foobar2000. In addition, gapless playback in mpd is pretty hit or miss, and doesn't seem like a priority like it is for Groove Basin.

With regards to your media player problem - totally. I'm hoping beets can grow to encompass this feature (there is already conversion functionality built in).

[Ichimonji10]

Beets definitely is growing in that direction. It can already import e.g. zip files and automatically unpack them for you.

[ViktorNova]

I somehow have not heard of Beetz before, I will absolutely check this out! Thanks everyone for mentioning it

@yoasif I have actually avoided trying Madsonic/Subsonic because they use Java, which I don't want to run on my VPS. I might give Madsonic a shot if all other avenues fail though!

Has anyone ever tried Jinzora? https://github.com/jinzora/jinzora3

I just stumbled on it, and it looks like it does all the things we're talking about and the screenshots of the interface look nice..even has companion apps for iOS and Android, web player, and supports various streaming options for other clients, as well as MPD support. Looks perfect on paper, but then again I thought the exact same thing about Ampache, which ended up doing nothing but hurting my brain when I actually installed it

Their website no longer exists..a little weird. I'll give it a whirl when I have a little free time and report back, unless anyone recommends me not to? =)

[Ichimonji10]

Is there any particular reason you're avoiding Java, @ViktorNova ? Worried about memory usage? You can adjust how much memory Subsonic is allowed to consume, and the default is 150MB. That said, on my machine, subsonic+java consume a total of 250M of memory. Depending on your VPS, that... might actually be an issue.

Jinzora appears to be abandonware. There have been no commits in about three years. (Also, it's 95% PHP. Depending on your prejudices, that could be good or bad.)

[ViktorNova]

I'm trying to avoid Java because it's a large stack that I wouldn't be using for anything else, and also because it's a 100% foreign beast to me, and I'm someone who likes to tinker with things

I don't mind PHP when it's done well and uses Ajax! =D But that is usually not the case, especially with projects 3 years dead. If I happen to try Jinzora out I will report back, but I'm going to give Beets a whirl first, it looks really cool and I'm finding that Python web apps can be quite good!

[yoasif]

beets is really more of a CLI app, the web plugin is a bit underpowered currently.

[Ichimonji10]

@yoasif is correct: beets is really command-line oriented. Its web interface is extremely limited; I'm not sure it's even capable of displaying a browseable list of your entire library. Also, if you (@ViktorNova) do ever decide to give Subsonic a shot, check out the Arch wiki page on the topic. It might make your life a lot easier.

[jprjr]

I just tried installing Madsonic, and it's kind of cool, but it's a nightmare to setup compared to Groove Basin.

• To enable transcoding, you need to setup symlinks to command-line transcoders
• It allows you to upload, but it doesn't auto-organize anything for you
• It uses a Flash-based player by default. It seems like there's an HTML5 video player, but I can't figure out how to play audio without Flash
• It's not compatible with MPD, Ampache, nothin' (as far as I can tell)
• I don't think it supports gapless playback at all, at least not when you're streaming

If you took some of the cooler features of Madsonic/Subsonic (like making + sharing playlists, multiple users streaming different things at the same time) and added it to Groove Basin, it would be pretty much the most perfect system ever.

[Ichimonji10]

The official Subsonic client does include a true HTML5 audio player, called MiniSub. However, audio playback defaults to using Flash, and video is flash-only.

Your other complaints are all accurate.

[Afterster]

Yeah Ampache sucks. It was good in the old days and didn't aged well. But since I took over Ampache project development with other peoples, we are trying to make it a better software. First new version since years was just released and there is still a lot of work to do... It getting better. Anyway, I'm historically an Ampache, Subsonic and Plex user since years and decided to contribute to development because no solution matches my needs. Ampache was the logical choice: other projects was abandoned, too young or didn't match my philosophy (Subsonic and Plex). Recently, Cherrymusic is definitely something to follow and I'm just discovering GrooveBasin thanks to this post. I don't know how I could have missed it. That said, I don't believe in an "unique" solution like you seem to look for. I personally use Ampache + Beets + XBMC + Subsonic clients, all linked together thanks to Ampache. Maybe it's something GrooveBasin should tends to, connectivity?

[andrewrk]

Hence, is Groove Basin a radio, a jukebox, or a personal audio player?

It's whatever we want it to be. It doesn't have to fit into one of these 3 labels.

Let's walk through a few use cases:

Walking through use cases is helpful - I prefer this kind of issue rather than asking a philosophical question which doesn't really have an answer.

What's her roommate to do? Suffer through the loud, annoying soundtrack, or look for a way to mute the music? After looking for a way to disable the sound, the roommate cuts the power, interrupting her stream.

This was solved with #129. There is now a button you can press in the web ui to toggle hardware playback.

One of the users has a meeting, and decides to pause the audio. The audio pauses for everyone. The user has brought his laptop into his meeting, and one of the other users on the Groove Basin station starts up a not-so-safe-for-work track (a user on the Groove Basin radio uploaded this track). The user is embarrassed, and is possibly reprimanded.

Issue #262 (not solved yet) addresses this use case. As is, the user should press 's' or click the stream button to stop streaming to prevent this scenario from occurring.

Focus on the personal audio playback functionality. The use-case here is one machine and a set of speakers.

This use case is indeed a priority.

The radio station functionality in Groove Basin is extremely confusing in the main UI. We should break out this functionality into a plugin or preference that users can disable or enable. The default option should be disabled.

This is not going to happen. Part of personal audio playback is providing the ability to listen at work or away from the user's main computer. Let's figure out what is confusing about the radio station functionality and update the UI to assuage it.

I'm not certain that users are actually interested in radio. If anything, I would envision some Subsonic or DAAP like music sharing like iTunes or Rhythmbox have would be more interesting to users -- with functionality like last.fm scrobbling, we could even emulate the current "radio" functionality by allowing users to "follow" scrobbles from a particular user, and play that music as they play it. This allows the client user to be able to play any music they wish, but also allows them to have access to the entire music library of the user without needing to force other users (like the owner of the Groove Basin install) to listen to what a single user would like to listen to.

You keep saying "radio". I don't think of it as "radio" so much as simply exposing my music library to the outside world. As the number one user of Groove Basin, I am certainly interested in this feature. It sounds like you're proposing an interesting feature request here which I think deserves its own issue. Feel free to open a new issue to start the discussion on that.

---

Groove Basin is not having an existential crisis. It is perfectly happy to be a mixture of a radio, a jukebox, and a personal audio player. There are certainly some interesting issues to resolve because of that, and let's discuss and solve all the relevant use cases in their own issues.