Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 13
  1. #1
    Junior Member
    Join Date
    Feb 2012
    Posts
    17

    CLI server messages for synched players

    Hi,

    I have a very ugly problem in my multiroom szanarios:

    I am using the SBS in combination with our home automation system and therefore using the CLI addresses by my SW on an iPad.

    The SW always connects to the player currently in use, thus only listening to messages for the player's specific MAC. The other messages are ignored.

    If this player is a member of a sync group and is NOT the "master" player (sync_master), the messages are send to the server starting with the current player's MAC (of course) but the messages from the server are only sent with the master player's MAC.
    This results in my SW (and player display) being wrong and not updating (!) because I didn't get (react) on those messages.

    This goes for commands like play, pause, skip etc, but obviously not power on/off (since the server is setup to power on/off all players at the same time).

    Is there any chance to make the server also respond to (at least) the player that has send the messages ?

    I do not really see a solution on the client side, because even if I check for the sync master on startup/player change and then faking the current player's MAC to that of the sync_master, this might have very very ugly side effects...

    I know this is rather complicated but maybe there is a simpler solution or anybody did have the same issue and could help me out of this dilemma...

    Thanks for any help on this,
    Markus

  2. #2
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,545
    A) Sounds weird, I don't see this. Are you talking about responses or notifications?
    Notifications should also be sent to all players, but they are usually delayed for players that are powered off. Responses should always ONLY come for the client to which you also sent the command.

    B) what are the problems you are expecting if you always use the master? That's what I do in iPeng and it actually works fine as along as you make sure it's not player settings you are trying to set.
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 7, the Universal App for iOS 7

  3. #3
    Junior Member
    Join Date
    Feb 2012
    Posts
    17
    (a)
    I am talking about responses. I am sending a command from one client (player) and I am expecting the answer to this response for this client, of course.
    But in the scenario described above, the response is for the sync_master instead, though the command was send with the other client's MAC address.

    (b)
    I was thinking of the workaroung you mention using the sync_master's MAC.
    This would mean a huge change in my SW because it works this way:
    1) user selects a zone (player)
    2) internally this MAC is stored and used whenever a command is sent or a message is received. I am subscribing using "listen 1" which in fact also gives me all messages/notifications from the server
    3) incoming messages are checked for this MAC and only handled when the message starts with the current (stored) MAC address

    How are you achieving this in iPeng? Are you - in case the selected player is synched - checking for the player status (returning the sync_master's MAC) and then react on this MAC's messages ?
    That's the only idea I do have but this also includes, that whenever a change in sync is made this data has to be updated...
    Seems as a dirty hack to me, and I am afraid of unknown sideeffects...

    Markus

  4. #4
    Junior Member
    Join Date
    Feb 2012
    Posts
    17
    Just for couriosity: Which interface are you using with iPeng ? CLI ?

    Markus

  5. #5
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,545
    Quote Originally Posted by MarkusKl View Post
    How are you achieving this in iPeng? Are you - in case the selected player is synched - checking for the player status (returning the sync_master's MAC) and then react on this MAC's messages ?
    First: As I said I don't see that issue although... I might not even notice.
    I use cometd, not CLI and that has a seperate request ID which is being used to identify the response, I don't think I even check the MAC.

    Apart from that, I keep track of all players and their respective sync states and I keep a meta level sync group identity which is always aware of the master and when I send commands to a group of synced players I only send them to the master (exception: player settings). The main reason is to avoid to accidentally turning on a player whenever somebody tries to play something on a group of synced players and the currently selected one is turned off, it's a common issue with synced Squeezeboxes and quite a number of people get confused about it although most of them probably don't even realize what the cause of the issue is.
    That's the only idea I do have but this also includes, that whenever a change in sync is made this data has to be updated...
    Indeed.
    Seems as a dirty hack to me, and I am afraid of unknown sideeffects...
    I don't think it's a dirty hack to have a comprehensive state model. serverstatus gives you all you need here.

    I needed to do that anyway because there are more things iPeng does per-sync-goup and not per-player, e.g. relative volume changes and power control.

    It's a lot of work, though, and yes, there are a few side effects (player settings being one, the other one is that menus are per-player and you can have e.g. different "Apps" for different players which is something you can confuse this way).
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 7, the Universal App for iOS 7

  6. #6
    Junior Member
    Join Date
    Feb 2012
    Posts
    17
    I agree, having a comprehensive status system isn't a dirty hack, of course.

    I meant, only faking the MAC address would, be though.

    As I read through your post, I am already thinking of doing something like that but with less efforts and intelligence - adequate to my problem.

    Anyways, thanks for the ideas and hints, I'll give it a try.
    Would be great if I could come back to you if there are further questions with this ?

    Thanks and regards
    Markus

  7. #7
    Junior Member
    Join Date
    Feb 2012
    Posts
    17

    Looks like a SB Server bug

    Hi pippin,

    I have to come back to this issue!

    I have analyzed the problem in more detail and against my thoughts to make a workaround or state system for the players I am now really of the opinion that this is a bug inside SB Server and has to be fixed there. Let me explain what I found:

    As stated before the central problem is that upon commands/requests (like playlist index +/-1 (next/previous song), play, stop, pause etc.) via the CLI interface for SYNCHED PLAYERS (let's say A and B whereas B is the sync_master) the response from the server is sent as a feedback to the sync_master's MAC address. Opening a putty session shows and verifies the MAC address of the sync_master rather than the MAC from the player the request was sent from (see example below).

    Let's still assume the sync process was originated from player B, still B is the sync_master.

    If one switches of the master player (B), now a status request for (A) does show that now (A) is the sync_master...??

    Switching on (B) again does NOT change this, still (A) is the sync_master when requesting the status with (A)'s MAC address which is confusing, because nonetheless (B) is always the master of the sync group when nothing is changed!

    BUT:
    If one also switches off (A) and on (A) again, THEN the sync_master for (A)'s status request states (B) as sync_master again.

    That said, the situation is not only very confusing, but also it is simply not possible to react on all possible situations. I am having a project with 15 zones/players (!!) within our home automation now and we do have >4 players in most of our projects. This is VERY confusing and our customers do expect an updated UI, of course.

    So, as also stated above by yourself, why not simply sending back the response to the player that has sent the request to the server ? This would be the expected and clean behaviour within client/server environments. Sending additional answers with the master player's MAC shouldn't harm, but definetely the requesting player should get an answer via the MAC in front of the response !
    As you said already, the requesting player should always get a response....

    Could you, please, check if this can be fixed within SBS and let me know what you think bacause after analyzing the issue again now destroys my idea of reacting to the sync_master's MAC address. In addition, this gives fu
    rther problems because when the volume changes, I do not want to react on a different player's volume change, since it's not within the current zone...

    I hope this helps clearing up what happens, I would really appreciate any help to come around with this problem !!!

    Regards
    Markus

    -----------------
    Example:

    player (A): 00%3A04%3A20%3A17%3Ad8%3Afe
    player (B): 00%3A04%3A20%3A22%3Aba%3A2f (sync_master)

    00%3A04%3A20%3A17%3Ad8%3Afe playlist index -1
    00%3A04%3A20%3A22%3Aba%3A2f playlist stop
    00%3A04%3A20%3A22%3Aba%3A2f playlist open file%3A%2F%2F%2FC%3A%2FSqueezebox%2FMusic%2520Coll ection%2F_BoL%25202012%2FMayday%2FCascada%2520-%2520Summer%2520Of%2520Love%2520(Extended%2520Mix) .mp3
    00%3A04%3A20%3A22%3Aba%3A2f playlist open file%3A%2F%2F%2FC%3A%2FSqueezebox%2FMusic%2520Coll ection%2F_BoL%25202012%2FMayday%2FCascada%2520-%2520Summer%2520Of%2520Love%2520(Extended%2520Mix) .mp3
    00%3A04%3A20%3A22%3Aba%3A2f playlist newsong Summer%20Of%20Love%20(Extended%20Mix) 19

    Here you see the sync_master is (B):
    00%3A04%3A20%3A17%3Ad8%3Afe status
    00%3A04%3A20%3A17%3Ad8%3Afe status player_name%3ASqueezebox player_connected%3A1 player_ip%3A192.168.178.43%3A26021 power%3A1 signalstrength%3A0 mode%3Aplay time%3A102.8347409935 rate%3A1 duration%3A302.053 can_seek%3A1 sync_master%3A00%3A04%3A20%3A22%3Aba%3A2f sync_slaves%3A00%3A04%3A20%3A17%3Ad8%3Afe mixer%20volume%3A2 playlist%20repeat%3A0 playlist%20shuffle%3A0 playlist%20mode%3Aoff seq_no%3A0 playlist_cur_index%3A19 playlist_timestamp%3A1335887344.29569 playlist_tracks%3A22

    Now switching off (B) and requesting status again for (A):
    00%3A04%3A20%3A22%3Aba%3A2f power 0
    00%3A04%3A20%3A17%3Ad8%3Afe menustatus ARRAY(0x86f735c) add 00%3A04%3A20%3A17%3Ad8%3Afe
    00%3A04%3A20%3A22%3Aba%3A2f prefset server power 0
    00%3A04%3A20%3A22%3Aba%3A2f menustatus ARRAY(0x7f2ef1c) add 00%3A04%3A20%3A22%3Aba%3A2f

    00%3A04%3A20%3A17%3Ad8%3Afe status
    00%3A04%3A20%3A17%3Ad8%3Afe status player_name%3ASqueezebox player_connected%3A1 player_ip%3A192.168.178.43%3A26021 power%3A1 signalstrength%3A0 mode%3Aplay time%3A195.88799108696 rate%3A1 duration%3A302.053 can_seek%3A1 sync_master%3A00%3A04%3A20%3A17%3Ad8%3Afe sync_slaves%3A00%3A04%3A20%3A22%3Aba%3A2f mixer%20volume%3A2 playlist%20repeat%3A0 playlist%20shuffle%3A0 playlist%20mode%3Aoff seq_no%3A0 playlist_cur_index%3A19 playlist_timestamp%3A1336064860.62573 playlist_tracks%3A22

    Switching on (B) again and requesting status again for (A):
    00%3A04%3A20%3A22%3Aba%3A2f prefset server power 1
    00%3A04%3A20%3A17%3Ad8%3Afe playlist open file%3A%2F%2F%2FC%3A%2FSqueezebox%2FMusic%2520Coll ection%2F_BoL%25202012%2FMayday%2FCascada%2520-%2520Summer%2520Of%2520Love%2520(Extended%2520Mix) .mp3
    00%3A04%3A20%3A17%3Ad8%3Afe playlist open file%3A%2F%2F%2FC%3A%2FSqueezebox%2FMusic%2520Coll ection%2F_BoL%25202012%2FMayday%2FCascada%2520-%2520Summer%2520Of%2520Love%2520(Extended%2520Mix) .mp3
    00%3A04%3A20%3A22%3Aba%3A2f prefset server volume 2
    00%3A04%3A20%3A22%3Aba%3A2f menustatus ARRAY(0x89222e4) add 00%3A04%3A20%3A22%3Aba%3A2f
    00%3A04%3A20%3A17%3Ad8%3Afe playlist newsong Summer%20Of%20Love%20(Extended%20Mix) 19

    00%3A04%3A20%3A17%3Ad8%3Afe status
    00%3A04%3A20%3A17%3Ad8%3Afe status player_name%3ASqueezebox player_connected%3A1 player_ip%3A192.168.178.43%3A26022 power%3A1 signalstrength%3A0 mode%3Aplay time%3A241.538786931992 rate%3A1 duration%3A302.053 can_seek%3A1 sync_master%3A00%3A04%3A20%3A17%3Ad8%3Afe sync_slaves%3A00%3A04%3A20%3A22%3Aba%3A2f mixer%20volume%3A2 playlist%20repeat%3A0 playlist%20shuffle%3A0 playlist%20mode%3Aoff seq_no%3A0 playlist_cur_index%3A19 playlist_timestamp%3A1336064860.62573 playlist_tracks%3A22

  8. #8
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,545
    You can find out about the current sync master from the serverstatus
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 7, the Universal App for iOS 7

  9. #9
    Junior Member
    Join Date
    Feb 2012
    Posts
    17
    Well, as said above, this isn't solving the issue itself.
    Is there any ambition from you or the SB team to fix this behaviour ?

  10. #10
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,545
    _I_ don't do anything on the server side. I'm just trying to help you
    ---
    learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
    Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
    at penguinlovesmusic.com
    New: iPeng 7, the Universal App for iOS 7

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •