Questions regarding music server options [solved]

I'm interested in streaming music from my unRAID server to my desktop PC at work, and I'm wondering what the recommended options are.  I can't install software on my work computer. So it would need to be something I can access in my web browser.  Ideally it would be something I have some sort of configuration control over.  I use Quod Libet as my music player of choice at home because it is so versatile, but I don't expect to find server software with browsing features on par with that.  If I could browse by artist, genre, and album that would be good.

Any thoughts? I saw Sonerezh listed in the Community Applications plugin.  That looks OK.  I tested the demo, and it meets the basic needs except genre browsing, but I was hoping for something a bit more flexible.  Ampache is another one I found on Google, but I don't know if there is a way to install it on unRAID 6.  The screen shots of it looked interesting.

I just recently updated to unRAID 6, and don't know what I'm doing yet with the new docker style plugins, but this post here is just about finding the right software.  Once I figure that out I can start a new thread on the appropriate forum on how to get it up, and running, if this is not the appropriate place, or we can keep it going here if that is OK.  Also I'm in no hurry to solve this right away.  I'm more or less in the early thought process on this.

To give you a quick backround I've been using unRAID for 5 years, but I've only ever installed basic plugins in the past, never one that ran an application, or a server before.

Have you looked at Subsonic?

Unevent, no I haven't.  Thank you for the tip.  I will certainly look in to it.

Edit: Trying it now.  I like it.  I can select a genre, and put it on shuffle.  That is more or less exactly what I'm looking for.  If I want Rock for an hour I can set that on shuffle.  If I get in a jazz mood, or whatever else after that I can switch.  This looks pretty ideal.

At the moment I've got to get to bed, but I'll play with Subsonic a bit more tomorrow night.  Thanks again for the tip.

I use Plex for a similar situation at work. As for Ampache, it appears you would just need to install the Apache docker and extract Ampache there. But that will require more work to get working than Subsonic, Plex or Emby.

Well I went ahead and installed Subsonic.  That went fine, but I'm not sure what I'm doing setting it up.  I believe I got the ports forwarded correctly on my router, but I'm not sure what's next in the actual Subsonic settings.  My Music share is named Music, so would the path be /Music?  I've also tried creating a user which didn't seem to work.

Is it installed on unRAID, if so is it a plugin or Docker?  Provide as much info as you can so people have an idea of how you are running it and how you have it configured.

I installed it via a plugin from "community applications". The author of the plugin is PhAzE.

Edit: I've attached a screenshot of the config page.  As you can see there are fields on the right that need information entered, but I'm not sure what to put.  Apparently the configuration is running in RAM too because I need to chose a directory.  I have no clue what the directory structure should look like in these settings.  I tried setting the music directory to /Music, but that didn't work.  Also initially the web UI button would launch me in to Subsonic, but that has now stopped working.  So clearly I've messed things up.

I installed it via a plugin from "community applications". The author of the plugin is PhAzE.

http://lime-technology.com/forum/index.php?topic=33341.0

Thanks Squid.  I'll give that a shot as well.  For now I think I'm going to call it quits for the night.  I've got work in the morning.  Thanks again.

Even though I don't use PhAzE plugins,  I can tell you this:  The run as user should probably stay as default (either root or nobody -> whatever it comes up with)

Also, your config isn't persistent and will be lost upon reboots (stored in RAM drive).  (hit the check box for the config folder?)

binhex - Madsonic docker

Dockers are the preferred way to do this sort of thing now instead of plugins.

Plugin or Docker...doesn't matter.

Lantesh, if you have a cache drive, set the install path for the plugin to a cache-only share, such as /mnt/cache/apps/subsonic.  Make 'apps' cache-only on the GUI shares tab, or prefix the folder with a dot: /mnt/cache/.apps/subsonic.  Setting it cache-only prevents the mover from moving your apps folder to the array.  Set the user as 'nobody'.  This is Linux thing to prevent the program from having administrator privileges.  Once Subsonic is running you can create users within the program.

Plugin or Docker...doesn't matter.

Disagree. I was writing a response then remembered this post in my links archive that does a very good job of describing the benefits of Docker over Plugins.

http://lime-technology.com/forum/index.php?topic=37581.0

Plugin or Docker...doesn't matter.

 

Disagree. I was writing a response then remembered this post in my links archive that does a very good job of describing the benefits of Docker over Plugins.

 

http://lime-technology.com/forum/index.php?topic=37581.0

You are entitled to your opinion. Both plugins and Dockers are supported.

To expand, plugins are simple and since there is one author of them they are typically damned reliable and only have to deal with the author/group of those making the program the plugin is wrapping.  Dockers have the same issue with the author/group that maintains the program the Docker is running, but you also have multiple Docker authors for containers of the same program each with his/her own personal twist on how it should be implemented.  There are multiple base images, personal twists like forcing the container to update every single time it is started sometimes making the end user wait several minutes or more while the package manager which has been micromanaged to a single mirror by the original author/group which always seems to timeout on updates anyway.  Other personal twists in the containers like having a cron to run every hour or whatever to check for updates.  A container in production should not do that.  Why make a users' container go from stable to crap automatically just for the sake of staying on bleeding edge?  An icon/link should go active on the Docker GUI letting the user know if an update is available and what it is - is it base package update or program update, etc..  Not the exact forum/topic for this discussion so I will make it somewhat short.  Don't kick the plugin author(s) in the shorts and don't get on your pedestal and preach everyone should move to Dockers when both Dockers and plugins are fully supported and available.

In addition to plugins having the potential of breaking core unRAID, it wasn't really very long ago when most plugins were broken by a change to core unRAID: Important unRAID 6.1 Plugin System Changes

Dockers were not affected.

A good rule to follow, especially if you are starting out and don't already have much invested in plugin setups, is use a docker if one is available.

In addition to plugins having the potential of breaking core unRAID, it wasn't really very long ago when most plugins were broken by a change to core unRAID: Important unRAID 6.1 Plugin System Changes

 

Dockers were not affected.

 

A good rule to follow, especially if you are starting out and don't already have much invested in plugin setups, is use a docker if one is available.

A mis-configured Docker can make unRAID unstable just the same.  If Docker Engine were to change in a future release requiring a change to existing containers to allow them to work then Dockers will face the same issue.  The change that broke plugins was due to implementation of security and feature enhancements to core unRAID and as a result has made plugins better, in my opinion.

And plugins have the potential to break each other. That was a major issue in v5 which has not been improved in any way by v6. The main reason it doesn't happen much is because we really only have one plugin developer (a single point of failure in its own way) still supporting these types of applications.

Yeah, sorry unevent, I'm with trurl on this one....

And the nice thing about dockers is there are different versions from different authors, I'm guessing by some of the things you've wrote you don't like our containers, that's your opinion and you're entitled to it, but some people do like the autoupdating. 

You could always use binhex versions that don't auto-update if you wanted.

But, I think it's now become widely accepted that except for core-unraid functionality it's probably better to run a docker container than a plugin wherever possible, for reasons that have already been stated.

And plugins have the potential to break each other. That was a major issue in v5 which has not been improved in any way by v6. The main reason it doesn't happen much is because we really only have one plugin developer (a single point of failure in its on way) still supporting these types of applications.

It was the Wild West for plugins in the past, yes.  Though not much different today as far as how containers are built/configured.  Its just LT has protected their interests by containerizing this 'userland' so errant authors/users can't easily break what they directly support as easily.

And plugins have the potential to break each other. That was a major issue in v5 which has not been improved in any way by v6. The main reason it doesn't happen much is because we really only have one plugin developer (a single point of failure in its on way) still supporting these types of applications.

 

It was the Wild West for plugins in the past, yes.  Though not much different today as far as how containers are built/configured.  Its just LT has protected their interests by containerizing this 'userland' so errant authors/users can't easily break what they directly support as easily.

Yeah, sorry unevent, I'm with trurl on this one....

 

And the nice thing about dockers is there are different versions from different authors, I'm guessing by some of the things you've wrote you don't like our containers, that's your opinion and you're entitled to it, but some people do like the autoupdating. 

 

You could always use binhex versions that don't auto-update if you wanted.

 

But, I think it's now become widely accepted that except for core-unraid functionality it's probably better to run a docker container than a plugin wherever possible, for reasons that have already been stated.

Wasn't naming names or pointing out specific authors/groups, only using as examples of how personal interests are put into containers.  I believe the point of Docker was to make it easier for the user to expand on their original purchase with reduced risk of causing core unRAID problems.  I think it does that fairly well as long as the user handles the setup configuration correctly and the container author has not personalized it too much to cause end user problems/headaches.  Plugins are still there and the core unRAID still operates using them.  They have come a long way since they were first implemented and as long as LT is still providing the hooks in their product for them they should still be allowed to be made and used if an end user wants to use them.

And plugins have the potential to break each other. That was a major issue in v5 which has not been improved in any way by v6. The main reason it doesn't happen much is because we really only have one plugin developer (a single point of failure in its on way) still supporting these types of applications.

 

It was the Wild West for plugins in the past, yes.  Though not much different today as far as how containers are built/configured.  Its just LT has protected their interests by containerizing this 'userland' so errant authors/users can't easily break what they directly support as easily.

So you finally agree

lol..not discounting the value of Dockers, the point was it was the Wild West for plugins and now it is the Wild West for Docker containers....it is just LT has moved the problem further away from their interests which was smart on their part. 

a docker is sandboxed from the host, in my experience there has been one docker that has affected the host adversely and it was due to the way the container made btrfs snapshots.

plugins are a nightmare for dependencies and dependency hell was the term coined for it, for it to be given it's own term gives you an idea of the scale of the problem.

Wow I missed a lot here over the past couple of days.  Sorry guys I haven't had time to check in, and work on this since my last post.

As for docker vs. plugin I'm going to be honest, and admit I really don't understand what the differences are because I haven't read up on it. I just upgraded to unRAID 6, and had never even heard of dockers until last week.  At present I have Subsonic installed as a plugin, and I will stay with the plugin version for now.  I'd like to get it functional, and once that is done I'll read up on dockers, and decide it I want to try that route later on.

So tomorrow I'll make some time to work on the configuration.  Thank you for the tips you posted.  I'll utilize them, and see if I can get it going.  Some additional info - I don't have a cache drive, so I'll have to create a share on the array, and set it to that.

Plugin or Docker...doesn't matter.

 

Lantesh, if you have a cache drive, set the install path for the plugin to a cache-only share, such as /mnt/cache/apps/subsonic.  Make 'apps' cache-only on the GUI shares tab, or prefix the folder with a dot: /mnt/cache/.apps/subsonic.  Setting it cache-only prevents the mover from moving your apps folder to the array.  Set the user as 'nobody'.  This is Linux thing to prevent the program from having administrator privileges.  Once Subsonic is running you can create users within the program.

This post was the most helpful of all the replies I received.  I actually got everything working now!  I just had to wrap my brain around a few things.

It took me a bit to realize that while the plugin was installed to my flash drive that the program itself was only running in memory.  Once I understood this it made more sense.  First I set up a share called apps, and inside that created a folder named subsonic.  I modeled this after Unevent's instructions listed above.  I don't have a cache drive so I put it on disk1.  I was then able to set the install, and config directories to this path.

The next issue I ran in to was I couldn't figure out how to map the music path to my music share.  I could set a hard path like I did with the install, and config directories, but not a share path.  I'm sure you can do it, but I couldn't figure it out.  So after thinking about it for a bit I reconfigured my music share to exist solely on disk1.  This way I could hard map to it, and when accessing the server remotely I'll only be spinning up one drive.  I'd like to know how to properly list the share path at some point, but for now it isn't relevant anyway as the hard path works.

The next issue I ran in to was accessing Subsonic outside of my local network. I forwarded port 4040 as the instructions indicated, but it simply wasn't working.  I not only forwarded the port from my router, but also from my modem to the router, so this really had me stumped.  I ended up finding the solution on a router support forum where someone having the same problem stated his solution was to put the IP address for his router in the DMZ on his modem.  This worked!  So for some reason my modem would not push the traffic through port 4040 even though I had it set to forward it, but by putting my router IP in the modem's DMZ it opened things up.  I suppose this is less secure, but my router in theory should stop all unwanted incoming requests.  The fact that a port is open at all is a security risk.  I may have to look at alternate methods in the future, but for now I'm just happy that it is working.

Thanks everyone for all of your assistance.  You advice was invaluable, and got me through this.