Posted by Steve on Tue 19 Jul 2005 at 14:28
If you have a large music collection then streaming it across a LAN, or the internet, is a logical thing to do with it. There are several different streaming servers available in the Debian package archives, here we'll have a look at GNUMP3d.
I've postponed writing about this for a long time, because I'm fairly biased, but I'll try not to let that affect me too much - clearly this is the best multimedia streamer in the world ;)
The GNU MP3/Media Streamer is a simple application which makes it possible to navigate through your audio and video collection via a browser, and stream playlists across a network.
Initially written as an alternative to the Python based Edna software it has evolved a lot since then.
The software supports browsing, searching, and streaming all via your browser with support for MP3, OGG Vorbis, WMA and many other types of audio files.
Installing the software is as simple as running:
apt-get install gnump3d
This will download the software and start the debconf based configuration. When the software is installed it will ask you three questions:
Each of those settings can be changed as you wish - either initially, or by later running:
dpkg-reconfigure gnump3d
It is suggested that you leave the server running as a dedicated user, although if you wish you could change this. (A common change is create a dedicated musical archive with ownership set to user and group music, then add the gnump3d user to that group).
Once the server has started it will create an index of the tags contained within your music. This tag database will be updated once a day via a cronjob located in /etc/cron.daily/gnump3d - to ensure it is constantly up to date.
Once the media is indexed then the server itself will start, and you can point your browser to http://localhost:8888/ to view your audio collection.
The interface is designed to be clean and simple to navigate, and several different themes are available. To change the theme you wish to use simply click upon the "Preferences" link.
If you wish you to customise the server you can examine and modify the configuration file /etc/gnump3d/gnump3d.conf. This file is commented fairly extensively.
The most common things users change are:
Security OptionsThe default theme can be changed simply by adjusting the following section in the configuration file:
## # # All the output the server produces is generated with the help of # some HTML template files, these are referred to throughout the # program and each collection of templates is referred to collectively # as a 'theme'. # # This next option allows you to specify which theme should be used # by default. (Any client can select one of the available themes by # the use of cookies). # theme = Tabular
Downsampling SupportThe security options of the server are two-fold. You can either:
- Restrict access to the server via a password file - less secure.
- Restrict access to the server via IP address - recommended.
To restrict access by username and password simply create a file called .password within the root of your music archive, containing lines of the form:
username1:password1 username2:password2This will prompt visitors for usernames and password. However if a visitor knows the structure of your archive they can directly download music without being prompted. This is because the server will always stream/serve media without authentication as very few audio players support it. The password option only protects your server from people viewing the HTML interface, and provides a small measure of security by obscurity.
The recommended way to protect your archive is to restrict the machine(s) which can access the server by IP address.
To that end there are two settings which can be used allowed_clients and denied_clients. These two settings are colon-seperated lists of IP addresses which are either allowed to connect or denied access respectively.
The commented out examples show how they can be used:
# # Only people on the same subnet, (class C): # allowed_clients = 192.168.2.0/24 # # Allow access to everybody on the LAN and one remote address # # allowed_clients = 192.168.1.0/24; 194.194.194.194
Downsampling of media is supported if you have a tool installed upon your server machine which can do the job, such as lame.
To enable downsampling you need to setup a couple of different options:
- First of all you must enable the downsampling option.
- Then specify the hosts for which it is enabled.
- Finally specify the commands required to do the job.
To enable downsampling set "downsample_enabled = 1". This will enable the support.
Once that's done you'll need to decide who gets their media downsampled. The way this is specified is by IP address - with two distinct groups. There are clients who always get their media downsampled, and clients who never have their music degraded.
The most common scenario is when the music server is installed upon a gateway. There the clients on the local LAN side of the gateway should never have their music downsampled, whilst those accessing it from the remote side should always have it reduced.
To do this is very simple, we start by saying "downsample to all clients", then modify that to ensure the local clients get the full bitstream:
downsample_clients = ALL no_downsample_clients = 192.168.0.0/24Again these configuration settings are commented in the configuration file.
Finally you need to setup the quality levels - these can be changed by the end user, so if you wish to mandate a particular quality level you should set all of them to the same.
The default quality level is "medium", and is altered via the default_quality option.
For each quality level, and each file type, you must specify a program the stream should be piped through.
The configuration options vary as they are designed to be flexible for different media types. They are constructed by the following "formula":
downsample_"quality level"_"file suffix"The examples given are fairly good though:
default_quality = medium downsample_high_mp3 = /usr/bin/lame --mp3input -b 56 $FILENAME - downsample_medium_mp3 = /usr/bin/lame --mp3input -b 32 $FILENAME - downsample_low_mp3 = /usr/bin/lame --mp3input -b 16 $FILENAME -Here the clients are presented with three different quality levels, 16, 32, and 56 bit streams. They can choose which level they get by altering the preferences in their browser - by default they receive the 32 bit stream.
If you wish to ensure they only ever get the low quality stream set:
downsample_high_mp3 = /usr/bin/lame --mp3input -b 16 $FILENAME - downsample_medium_mp3 = /usr/bin/lame --mp3input -b 16 $FILENAME - downsample_low_mp3 = /usr/bin/lame --mp3input -b 16 $FILENAME -
I guess the biggest issue with it is the inability to create and save different playlists - I know that a lot of other servers allow that KPlaylist for example.
Still it's a nice stable server, and does everything I need it to. Development is pretty much ceased, although I don't really regard that as a bad thing - there's very little that could be added without complicating it more.
(The issue of using a database backend gets raised every now and again, but is unlikely to ever occur).
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
I did produce a small experimental server using a database backend to see how much speed gain there could be and how much effort would be involved in making it optional.
As expected indexing the music archive became both simpler, and faster, and the rest of the server was largely unaffected. It seemed like too much work to integrate the changes into the main project and make them "optional" though - so the work was abandoned.
I do small amounts of development every few months. But things are very slow with nothing substantial changing between releases. The only real changes recently have been new themes contributed by users, and the occaisional bugfix - if anybody suggests something very novel and useful/interesting I'd be tempted to add it - but not at the expense of increasing complexity.
(In case it's not clear I wrote the code; hence my mention of bias at the start of the article).
Steve
-- Steve.org.uk
[ Parent ]
Yes, that'd be why my name is on the bottom of each page upon the gnump3d.org website, etc.
Of course other people have sent patches, big and small, they are credited in the AUTHORS file.
Steve
-- Steve.org.uk
[ Parent ]
Hey use whichever program you prefer!
Zina is a nice alternative too, simple and clean.
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
Good choice - I was listening to them earlier!
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
Nice try!
Google is your friend .. there are a few servers out there which are publically accessible. I'm not sure I should encourage anybody though ;)
Steve
-- Steve.org.uk
[ Parent ]
--
Serge van Ginderachter
[ Parent ]
To use the web interface you'll obviously need a browser of some kind.
I've heard of people using iPaqs and other wireless PDA-type clients for recieving and playing the music. Personally I just use xmms and firefox running on a desktop with speakers attached, or a laptop.
Sorry I couldn't be more helpful.
If you're looking for a black-box type device for receiving music from a central location you're probably going to want to look at something like the Squeezebox from SlimDevices, although I've never had the money to spare on one of them!
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
If you're happy with your existing solution there may not be a lot of reasons to switch.
What this solution does offer though is:
It really depends what your usage is. Some people will load up a massive playlist with all their songs in it, and just play that randomly. Other people prefer to load specific things based upon their mood - that is probably a scenario better suited to a dedicated streaming server.
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
Error
The requested file /mp3/99/U2 - Sunday Bloody Sunday.mp3.m3u couldn't be found. Please try returning to the index.
--
Serge van Ginderachter
[ Parent ]
[ Parent ]
[ Parent ]
One of the initial goals was to make it as simple as possible to setup and use.
With the support for downsampling things got a little bit more complex, and when Windows support was bolted on some more changes were introduced which spoilt things a little.
But on the whole I think it's still simple to setup and use for 99% of all users. Which is a good thing.
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
The server isn't really setup to allow that. I suspect you'd just get frustrated unless you were capable of getting other people to all start playing the same playlist at the same time.
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
[ Parent ]
I've thought of it several times ;)
The hard part is doing it securely - usually I suggest instead that people use an ssh, or ftp server to manage the uploads. Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
Not a bad idea.
Right now the file suffixes of all supported media is contained in the library file lib/gnump3d/files.pm - so that's the place I check first.
It's not very obvious though, and a list might be useful to lure more users in.
Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
[ Parent ]
Sadly not at the moment. Most of these strings are contained in the template files you'll find beneath /usr/share/gnump3d - you could edit them there, but an upgrade would remove your changes.
It hadn't really occurred to me that this might not be the most appropriate label, although I guess things like "audio books" shouldn't really be called songs. Steve
-- Steve.org.uk
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
I guess the perl debugger/profiler is the obvious approach...
Personally I restart it once a week for the addition of new music, so I've never seen this. Maybe that is a "solution"? If you could track down any issues I'd fix them .. but I guess coding your own replacement is just as good an approach ;)
[ Parent ]
[ Parent ]
It was removed because none of the people volunteering to maintain the package actually did so.
These days I'd probably pick mpd/mpc for controling music, but if you specifically want streaming then I'd suggest libapache2-mod-musicindex.
[ Parent ]
[ Parent ]
[ Parent ]