PDA

View Full Version : Different sets of music for different Squeezeboxes?



Andy Marks
2004-09-27, 09:33
That's pretty much the same thing I want to do.
The rest of the family doesn't seem to like Merzbow as much as I do. :-)

After thinking about it some more, it seems like there needs to be a way to
specify music subsets which are defined by a series of filter (ie create a Kids subset that
would only contain stuff where Artist=Raffi or Genre=Videogame etc). Then there would
be a way from the Squeezebox UI to select a subset to use and then drill down through those
using the standard UI.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com on behalf of Rob Walker
Sent: Sun 9/26/2004 11:22 PM
To: discuss (AT) lists (DOT) slimdevices.com
Cc:
Subject: [slim] Different sets of music for different Squeezeboxes?



On Saturday 25 September 2004 05:02 pm, Jonathan Miller wrote:
> I don't think two instances of slimserver can run concurrently. I
> imagine you might try two seperate playlists for your two rooms. In
> my experience I've had multiple players, be they actual Slims, or
> through iTunes, or XMMS, and played different songs on each player at
> the same time.
>
> On Sat, 25 Sep 2004 15:25:48 -0400, Andy Marks <andrew.marks (AT) wise (DOT) com>
wrote:
> > Prospective Squeezebox owner question here:
> >
> > Is it possible to have different sets of music available to different
> > Squeezeboxes using the same server? I have quite a large collection of
> > music (~950 albums) and I can see where I might want to get 2
> > Squeezeboxes (for 2 different rooms in my house) where only a small
> > subset of my collection would need to be available for one room.
> >
> > Now that I think about it, can multiple instances of the server be run on
> > the same machine? If so that might be one solution.

I was going to try this before posting about it, but I saw your post first, so
I will add my request here. If someone thinks it is useful, I will put it in
the bugtracker.

I have one SB, soon to be an SBG, and an original box as well. I was thinking
it would be nice to give the boys (6 and 4) the remote for their room, but
using a different server running with a different music subset (something a
litlte bit more age-appropriate than all of our collection, you know?).

I also have a request in from the wife to have a web interface which only
shows the music which we want to see at the moment. I have considered
different collections of music, which transcends genre or playlist. "kids",
"sleepytime".



My first thoughts were to create a mirror of the children's music, and have a
separate slimserver running against that config file, with that set of music.


Here is what happened:

/usr/local/src/SlimServer_v5.3.0/slimserver.pl
--prefsfile /etc/slimp3-kids.pref --playeraddr 192.9.200.193 --httpaddr
192.9.200.193 --cliaddr 192.9.200.193 --logfile /var/log/slim-kids.log

but it didn't start, with the following error in /var/log/slim-kids.log ...
2004-09-27 02:35:02.7703 Problem: There is already another copy of the
SlimServer running on this machine. (Address already in use)

a grep through the code points to

Slim/Networking/Protocol.pm:83: msg("Problem: There is already another
\
copy of the SlimServer running on this machine. ($!)\n");

and that is in the UDP port binding code.
I lokoed at the output of "netstat -ln", and realized that the server binds
itself to 0.0.0.0:9000 by default. I changed the command line for my default
server to be binding to the eth0 IP addy, and then ran the new one on eth0:0.

Oops, the server is still listening on 0.0.0.0:3483,

I had to hack on /usr/local/src/SlimServer_v5.3.0/Slim/Networking/Slimproto.pm
and change line 27 from

my $SLIMPROTO_ADDR = 0;

to

my $SLIMPROTO_ADDR = '192.9.200.192';

start the server, then change the file to

my $SLIMPROTO_ADDR = '192.9.200.193';

and then start the server again. Now lsof does show UDP and TCP connections
on two different IP addresses. I was confused as to how --playeraddr works,
I guess. I tried putting

my $SLIMPROTO_ADDR = $localClientNetAddr;

but got a perl error, so that's not good.


This should really be architected into the system, and not hacked in like I
just did. I think this might work, the servers are at least both runinng...

There are a few variables which could be all updated based upon one larger
variable ($collection_name, $collection_iface?), and then the different
variables I messed with would get built from there.


rob