Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23
  1. #11
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,179
    Quote Originally Posted by pputzer View Post
    I gather that the commands are run on the LMS server itself, though?
    Correct

    We'd still need a daemon on the player to act on the events?
    No, the server can execute commands on the clients e.g. with ssh
    The external command run by the plugin gets the player / client information (technically, the LMS player status) passed as a parameter, so that's easily done in e.g. a shell script.
    Various SW: Web Interface | TUI | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | DB Optimizer | Chiptunes | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  2. #12
    Senior Member
    Join Date
    Mar 2010
    Posts
    191
    Quote Originally Posted by Roland0 View Post
    No, the server can execute commands on the clients e.g. with ssh
    The external command run by the plugin gets the player / client information (technically, the LMS player status) passed as a parameter, so that's easily done in e.g. a shell script.
    So the script would have to parse the player ID from the parameter? While doable, that does not seem "easy" to me. While the functionality overlaps, I don't see any benefits in having event subscription happening in an LMS plugin (as opposed to a daemon using the CLI).

  3. #13
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,179
    Quote Originally Posted by pputzer View Post
    So the script would have to parse the player ID from the parameter? While doable, that does not seem "easy" to me.
    Code:
    PLAYER_IP=$(echo $2|grep -o '"[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*:'|tr -d '":')
    PLAYER_NAME=$(echo $2|sed -e 's#\(.*"player_name":"\)\([^"]*\)"\(.*\)#\2#')
    While the functionality overlaps, I don't see any benefits in having event subscription happening in an LMS plugin (as opposed to a daemon using the CLI).
    Nothing to install / run on the client, zero dependencies
    Better performance / less overhead
    Simpler implementation
    Generic solution for all events
    Various SW: Web Interface | TUI | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | DB Optimizer | Chiptunes | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  4. #14
    Senior Member
    Join Date
    Mar 2010
    Posts
    191
    Quote Originally Posted by Roland0 View Post
    Code:
    PLAYER_IP=$(echo $2|grep -o '"[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*:'|tr -d '":')
    PLAYER_NAME=$(echo $2|sed -e 's#\(.*"player_name":"\)\([^"]*\)"\(.*\)#\2#')
    So what is passed to the script? The output of the `players` CLI command? I haven't found any documentation on this anywhere.

    Quote Originally Posted by Roland0 View Post
    Nothing to install / run on the client, zero dependencies
    Better performance / less overhead
    Simpler implementation
    Generic solution for all events
    For someone seeking a completely custom automation solution, sure. For other use cases, I don't think that having everything on the server is actually a benefit. Performance wise, I doubt there will be much of a performance difference for most scenarios. There might be if the raw computing power of the server vastly different from the player (say a desktop computer and an RPi Zero). Even then, I'd wager that the actual limiting factor will be the network roundtrip, and that's going to be there either way.

    Installing shell scripts and configuration files on a NAS is far more involved than on a piCorePlayer (even more so if a solution could eventually be integrated into the main distribution). I think the Perl motto is very apt here: TMTOWTDI

  5. #15
    Senior Member
    Join Date
    Mar 2010
    Posts
    191

    Feature parity with real Squeezeboxes

    I've looked at the IR Blaster plugin and the Jivelite code in more detail. To support native IR Blaster functionality, Squeezelite would have to be extended to process the undocumented blst frame of slimproto. That should be doable for Linux/Raspberry, but I'm unsure whether this is a worthwhile approach. (The IR Blaster plugin would then have to be adapted to send IR commands to Squeezelite players.)

  6. #16
    Senior Member
    Join Date
    Mar 2010
    Posts
    191

    New release of Squeezebox IR Events

    I've released a new version of the Squeezebox IR Events daemon. It can now run arbitrary scripts.

  7. #17

    problems getting this to work

    Thanks so much for this work. I have had to retire my SB3 and am badly missing the blaster functionality to control my amp. After stumbling on this I gave it a crack (with limited skill) but was not able to get it to work properly. Below are my findings after some testing using the standard web GUI with both squeezelite and duet players with LMS 7.9.3. My goal is to have this working with iPeng so that volume changes on my phone are blasted to my amp.

    1. The power events appear to work fine but they are of no real interest to me
    2. Whatever variation/combination that I tried, I could not get any proper detection of the volume events, which is my entire motivation
    - In the GUI clicking on the softer/louder buttons on the end of the volume slider, nothing happens
    3. If I clicked somewhere along the volume slider I get an error - invalid syntax for integer with base 10: ' ' & not further (power) events are detected.
    4. If power event definitions are removed from the config, the script crashes.

    Any suggestions on how to get the volume to work ??

    thanks !
    Last edited by davemal; 2020-10-29 at 20:46.

  8. #18
    since my last post, I thought that I would try version 0.1, which uses irsend only. Thats ok by me as I plan to use irsend anyway.

    This version at least detects the volume events but its so inconsistent & delayed that its not usable. More often than not it didnt detect volume changes and when it did, it was rarely instantaneous. It appeared also that decreases in volume sometimes triggered the increase script but that possibly could have just been lag from previous adjustments..

    Is there something that I am missing ?

  9. #19
    Just noticed that you need to install the VolumeLock plugin to get this to work.

    Unlike the IRBlast plugin, there appears no way to blast while NOT adjusting the player output levels...

  10. #20
    Senior Member
    Join Date
    Mar 2010
    Posts
    191
    Quote Originally Posted by davemal View Post
    Just noticed that you need to install the VolumeLock plugin to get this to work.

    Unlike the IRBlast plugin, there appears no way to blast while NOT adjusting the player output levels...
    Yeah, wanted to suggest that, but did not get around to experiment with it. I don't think that blasting without VolumeLock is useful (but of course, the daemon should not crash).

Tags for this Thread

Posting Permissions

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