PDA

View Full Version : Overlapping groups in LMS, dynamic join/leave of player groups, or mute them?



belgianguy
2014-02-06, 14:43
I was wondering how I could make the following scenario work:

Let's say I have 5 player devices (Most likely Raspberry Pi/SqueezeSlave with their own usb soundcard), all connected to a single LMS.

Let's call them 1, 2, 3, 4, 5.

Now, at 8.30am, I want to play a song on 1, 3, 5. But 2 and 4 should not play.

At 10.00am, I want them all to play.

And at 16.00pm I just want 2, 3, 4 to play. Devices 1 and 5 should not play.

The astute observer has noticed that device 3 is in all the 'play' scenarios. 1 and 5 are in the 'morning' group, 2 and 4 are in the 'afternoon' group.

I haven't been able to figure out how to accomplish this, LMS has sync functionality, but I don't know if it can handle these scenarios:


1. Use an outside process or script that runs on the same server (Ubuntu), that can tell LMS (through CLI?) which players to sync at what times (some minutes before playback should start). LMS itself would just play to the devices it can see at that time and not need any changes itself.

2. Dive into the code (slimserver on Github), somehow gain access to the array that stores the connected client IP addresses and add logic to the playback to make sure that when an alarm is played, it'll only be sent it to the devices that need to play at that time. Would be a steep learning curve, and might not be feasible. (I'm a programmer with sufficient network knowlegde, so the technical aspect doesn't scare me, the reliability of such an implementation, however, does)

3. Play on all devices, but send the devices I don't want to hear at that time a mute signal beforehand (volume 0).


PS: I'm reading a lot of conflicting reports on software players not wanting to synchronize right, are these isolated cases, bad configurations, ...? The whole above paragraph is void if syncing cannot be accomplished reliably.

garym
2014-02-06, 14:54
not sure about your variable sync groups quesation, but I can assure you that I have multiple SB players that can sync perfectly (even when at two ends of same room, so even a tiny bit off would be very obvious).

pippin
2014-02-06, 16:01
Have a look at the CLI. The documentation comes with the server under "Help".
You'd probably want to use JSON/RPC to actually send the CLI commands, search the developer section in this forum for JSON/RPC.

Oh, and you don't want to use mute, you want to use the power state.

How well player sync works for software players depends on what platforms they run. If the devices are similar (or even the same computer) it should work but if you want to sync a Windows PC to a hardware player you'll probably have bad luck.

DJanGo
2014-02-07, 00:22
Have a look at the CLI. The documentation comes with the server under "Help".
You'd probably want to use JSON/RPC to actually send the CLI commands, search the developer section in this forum for JSON/RPC.

Oh, and you don't want to use mute, you want to use the power state.

How well player sync works for software players depends on what platforms they run. If the devices are similar (or even the same computer) it should work but if you want to sync a Windows PC to a hardware player you'll probably have bad luck.

Hi,

@pipin did you cross check whats happen if a synced player is powered off and lms starts to play?
I'll think lms just powers him on and it will play.

So muting these player should be (untested) the real deal instead of power on/off :confused:

Since he wants hard coded times and uses ubuntu - i'll think a (couple of) cronjob(s) is easier to manage instead of json/rpc.

I would manage that with a fade in / out script eg.
if its 8.59 am mute all players, if its 9.00 unmute player y,x,z to 50% and on 9.01 umute players xyz to 100%.
Same with the other times.

Should be just a very simple easy job 2 do.



cheers

belgianguy
2014-02-08, 06:37
Ah, thanks for the insights guys! I'll look into the CLI, I'm very curious if I can get a setup going with some old boxes I have lying around here, I'll throw Ubuntu on them and see if I can have them stay in sync.

Are cronjobs accurate enough to fire the 'play' events? I was looking into writing a service on the server that essentially busy-waited until the timestamps had arrived, and then fire the events. But that might be a waste of resources and time if cron can do all that.

Of course that doesn't mean that my Raspberry Pis will stay in sync, but it'd give me a glimpse on the deciding factors. I was planning on syncing them up to NTP anyway, hoping that'd help keeping them in sync, but I haven't really looked into the protocol.

While the mute option sounds easy and attractive, I feel sending a command to a box which then executes it muted, gives the wrong idea from an engineering perspective. In this case I'd rather not have sent anything at all. But I might be overthinking things a little.

DJanGo
2014-02-10, 05:24
Hi


Are cronjobs accurate enough to fire the 'play' events?
well yes or no - in case of LMS supports the Alarm for different times you can hadle whats to play better / in a gui not in a script.

So i would solve the start playing via the alarm - the "syncing" via cron.
Since the Server is the master of sync its always a good idea to use a ntp Server (on the lms) and ntp client on the pis - cause of the lack of a clock on the pi. (Not a issue for the lms synching - but one network only one timestamp is always a good idea.)

as you can read in one of my threads:
The Only strange thing i noticed is - if one Player is playing and i want to sync that with a sleeping - means powered off - one, both dont play.
Just power the other one on before syncing works.


While the mute option sounds easy and attractive, I feel sending a command to a box which then executes it muted, gives the wrong idea from an engineering perspective. In this case I'd rather not have sent anything at all. But I might be overthinking things a little.

bahh "gives the wrong idea from an engineering perspective" Kiss means short and simple or stupid and simple.
call me stupid engineer ;-)


i would name the Player like morning1; morning2 or something like that to handle what it should done.

I think (know) its a JOb less 2 hours incl. tests to write that type of script.

DJanGo
2014-02-10, 13:37
just a simple script for your own startup

This code (i hope you know how to implement that on your server) wants 2 parameters:

shellname.sh playername mute
or
shellname.sh playername unmute

I think its better to slowly "wake up" the speakers/visitors than simple pull the pedal to the metal -so i just added a sleep 1 between each volume change. And for muting i'll ask the actual volume from the player count from 100 (max) to 0 and only if the volume is less than that set the volume for the player to the new value (otherwise it will eg sets the volume for an player thats on 50% in one big step to 100% and then mutes him down)

Have fun with the code :cool:
edit even when i didnt added some ### / Rems


#!/bin/bash

##vars
port=9090
server=localhost

# get number of known players
players=$(printf "player count ?\nexit\n" | nc $server $port | cut -d ' ' -f 3)

## check all known players
for((i=0; i<$players; i++))
do
playerID=$(printf "player id $i ?\nexit\n" | nc $server $port | cut -d ' ' -f 4 | sed 's/%/%%/g')
playername=$(printf "$playerID name ?\nexit\n" | nc $server $port | cut -d ' ' -f 3)
vol=$(printf "$playerID mixer volume ? \nexit\n" | nc 127.0.0.1 9090 |cut -d ' ' -f 4)

if [ $playername = $1 ]
then
if [ $2 = mute ]
then
for v in {100..0..-5}
do
sleep 1
if [ $vol -gt $v ]
then
printf "$playerID mixer volume $v \nexit\n" | nc $server $port
fi
done

fi
if [ $2 = unmute ]
then
for v in {0..60..5}
do
sleep 1
printf "$playerID mixer volume $v \nexit\n" | nc $server $port
done
fi
fi
done

belgianguy
2014-02-10, 15:00
Hi DJanGo, thanks so much for the insights and the code, your script-fu is certainly more advanced than mine! :)

Also the caveat regarding an 'off' player is noted! I was also contemplating using 'soft' increases in volume as to prevent any crackling or squeeking.
The NTP syncing shouldn't be a problem I think, I've found some guides and tutorials, like this one: http://www.cyberciti.biz/faq/rhel-fedora-centos-configure-ntp-client-server/.

The only thing worrying me is that I have some rather 'remote' locations for about 3 players. I could have RJ45 cable pulled there, but it'd up the costs significantly.
I just don't think wireless is going to cut it, as it suffers from dropped packets by design and its throughput never will match that of cable, and it'd probably mess with my syncing, too.

Well, guess I'll get testing with alarm and cron, trying to sync players, see how reliable it is. I've found 2 old boxes that aren't in use anymore, although their hardware differs greatly.

It's all starting to take shape and I see a lot of potential here! But I like planning things up until the very minutiae, so I'll be sitting at this desk for a while before the real machines arrive... :)

Thank you very much for all the help you provided!

Mnyb
2014-02-12, 21:34
@pipin did you cross check whats happen if a synced player is powered off and lms starts to play?
I'll think lms just powers him on and it will play.


Actually its a player setting if power should follow sync or not ,similar for volume it can also be synced or not.

(no insight on your scripts )

DJanGo
2014-02-13, 00:25
@pipin did you cross check whats happen if a synced player is powered off and lms starts to play?
I'll think lms just powers him on and it will play.


Actually its a player setting if power should follow sync or not ,similar for volume it can also be synced or not.

(no insight on your scripts )

Hi Mnyb,


The Only strange thing i noticed is - if one Player is playing and i want to sync that with a sleeping - means powered off - one, both dont play.
Just power the other one on before syncing works.

Ahh never noticed.. You mean:
In the 3rd Line from Player settings sync "power management in group"?
I just do that on each players - works fine execpt if i power one of them off - all others stopps playing. (Powered off also)

Did you know if the Master Player should not had this setting?

cheers
(even old "wise" guys learn each day something new)

pippin
2014-02-13, 06:53
@pipin did you cross check whats happen if a synced player is powered off and lms starts to play?
I'll think lms just powers him on and it will play.


Actually its a player setting if power should follow sync or not ,similar for volume it can also be synced or not.

(no insight on your scripts )

Well, "LMS" never starts to play but a player does, "play" is always a player-specific command. If you press "play" on the player that is turned off it will turn on, no matter if it's synced or not. If you do so on another player in the group it depends on the player preference you mention but I believe if you rally sync power the two players can never have different states.

pippin
2014-02-13, 07:04
I should also mention that I believe that power handling in synced groups is one of the most problematic aspects in the way Squeezeboxes sync. It's one of these cases where flexibility hurts usability.

The problem is that people are often mistaken about the player they actually control. This is most imminent in the web interface which sometimes changes players completely on it's own but it can also happen on the controller or in the Apps. The Apps show the player name but then people often just don't look or have too similar names.

What happens then is that you accidentally power on the wrong player. If you browse the forum you'll find quite a number of reports of players "turning on on their own". I am convinced 90% of these are due to this very effect (there is one other one: Radios rebooting and then starting to play immediately but that's more rare).

I had these complaints on a regular basis from iPeng users in the past until I introduced the rule the iPeng's "play" commands are always only sent to the "master" player in a group. LMS makes sure that if at least one player in a group is powered on, the "master" is always one of the players powered on. This way, iPeng never turns a synced player on if you play something on another player. Since then, I never got the complaints again...

This sounds like a minor issue but only until the first time you accidentally power on the player in the bedroom where your beloved one's currently sleeping at 2am....

DJanGo
2014-02-14, 12:37
What happens then is that you accidentally power on the wrong player.

This sounds like a minor issue but only until the first time you accidentally power on the player in the bedroom where your beloved one's currently sleeping at 2am....

Hi Pippin,

i may completly agree - but...
That "quote" above didnt make any sense ;-)

If someone had a sync for some players and he tells the LMS to tell the Players to Play :p :D - its no question that "all" players would play (if they are online)

So make a long story short....


Overlapping groups in LMS, dynamic join/leave of player groups, or mute them?

I would say wrote:D mute them - if he wants to use raspberrys with squeezeplayers he may got in trouble withe the machinegunterror after some idle time.

pippin
2014-02-14, 12:45
No, a player that is powered off "power state is off" will not start to play unless you explicitly tell it to, even if it's part of a sync group that starts playing.