Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 23 of 23
  1. #21
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,285

    Question for Michael (or a deep enough expert on LMS core)

    Quote Originally Posted by mherger View Post
    > But with virtual players, this is what you would get. If you change the
    > volume of one slave player, then only its volume changes. Only when you
    > change the volume of the virtual player itself will a proportional
    > change on all volumes happen. So if you don't want that, always use
    > slave volumes. That the conceptual difference between a group and a
    > virtual new player.


    Ok, I see. But I don't see this happen... That would be a massive change
    to LMS. Handling synced players is all over the place. Introducing yet
    another related, but different approach would be a big involvement.

    What I could imagine is the group approach. That would mostly be UI
    changes, plus a way to define and handle saved sync groups.

    I'll have to play with the virtual player idea. Mentally, at least. Can
    you send me a pull request when done? :-)

    --

    Michael
    If I can direct one question to you Michael, before trying the baby step with a set of "fake" squeezelite players (that I know how to do very well know ) but I'd like to know if it's possible to create such virtual player purely in LMS in Perl. I this is a dead end, I don't think I'll try because although the idea of a fake squeezelite instance is good to start, ultimately it means handling real audio content for it which I don't like. So if I can't have a player that is just a container for playlists, volume, commands & control (start, stop pause ...) and in fact a "link" to a real LMS group, then I don't think its worth the effort.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  2. #22
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,779

    UI change for sync groups

    I'm sorry, totally missed that one...

    > If I can direct one question to you Michael, before trying the baby step
    > with a set of "fake" squeezelite players (that I know how to do very
    > well know ) but I'd like to know if it's possible to create such
    > virtual player purely in LMS in Perl.


    I'm sure it's possible. But unfortunately I can't say for sure how hard
    it would be. I guess you'd have to create a new Slim::Player::xXX class,
    inheriting from Slim::Player::Client. This could potentially be done as
    part of a plugin, outside LMS.

    --

    Michael

  3. #23
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,779

    UI change for sync groups

    > I'm sure it's possible. But unfortunately I can't say for sure how hard
    > it would be. I guess you'd have to create a new Slim::Player::xXX class,
    > inheriting from Slim::Player::Client. This could potentially be done as
    > part of a plugin, outside LMS.


    I've been thinking over this idea a little more... There are technical
    challenges, and UX challenges. Inheriting from Slim::Player::Player
    might be one way to go. Groups would show up as any other player,
    keeping compatibility with client software. You pick it, start playback,
    and it would set up the syncing if needed.

    Sync group management in existing software (incl. the web UI, if not
    modified) would list the real players as synced to the sync group proxy
    player ("Upstairs"): "Upstairs, Bedroom, Kid's room". The individual
    players keep their own playlist.

    Changing the sync configuration from any of the members would behave the
    same as any synced group of players. They can leave the group any time
    they want. You could end up with one controller controlling the sync
    group, but all member unsynced, resulting in no playback at all. But the
    next time the sync group is "powered on", it would re-connect all other
    players. UX challenge...

    Sync group aware clients could use the new player model string to
    customize the UI to eg. show the sync groups in some other UI element.

    Sync groups need to connect to LMS automatically when LMS is started,
    using some fake MAC address. They come with their own set of prefs.

    My optimistic thinking tells me that this would be the most compatible,
    least technically involved approach, ignoring some of the UX challenges.
    Not perfect, but a huge improvement anyway.

    --

    Michael

Posting Permissions

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