Re: xPLMediaNet Devices Controlling Devices - important please

["timmysaw2" <timmysaw@xxxxxxxxx>]

--- In ukha_xpl@xxxxxxx, "Tony Tofts" <tony@x> wrote:
> Hi all,
>
> Would like some input from interested parties on devices
> controlling devices...
Hey that's me!

> Therefore I think the local display should be locked out, and as
> nothing can be seen I think local ir control should also be locked
> out. Basically the device becomes dumb while under the control of
> another device. Thoughts?
This would not be a favored mode of operation. I can see issues when
I'm in a separate room from the master and I'd like to change the
volume level (content playback should remain the same.)

>
> Alternatively, the devices could negotiate the smallest screen
> size and both work to that? It means if controlling a slim on an
> mvp the menu would be only 2 lines. What would users prefer?
I suppose this would be acceptable, but kind of funky. How often
does this really occur? Good to anticipate the issue. :-)

>
> Also, as the status screens on the devices are all different, I
> think that control should be automatically released when exiting
> the menu system? The master would return to where it was, so
> pressing enter would automatically restore the control of the same
> device. I see this master/slave relationship as a control one, not
> an emulation of all a devices characteristics (as these will be
> too many and varied).
I'm not clear what you mean by "restore the control" Why would
the
Master loose control (except over the single slave device)? Seems
like Local control of a slave device should only override audio
settings of that device and not effect content of other devices. If
the Local device alters content, then it exits Slave mode.
[he says confidently, then thinks about it a bit...] So perhaps it
would be more appropriate to capture inputs for track control and
direct them back to the master, just not Playlist/content selection.
I dunno. Maybe that is just too far over the line.

What about simply (ha--simple from my perspective...) changing which
device is the master when the playlist is manipulated (skipping
tracks, changing content, etc.) from that point on the new device is
the Master. This way each device always displays in "native" mode
and you don't have to try to squeeze one display into the other.

>
> Also, by default when a device becomes a slave it will jump to the
> music selection menu, though you can then navigate back to the
> devices own front menu if required
Seems odd. I would expect the Slave device to display whatever it is
doing...if you're playing back on the master, then the slave is in
playback mode.  Why would the slave go to the Selection Menu?  What
about just putting up a "Client Updating. Please wait..." message
on
the slave device?

> Still trying to work out a good way of releasing a device from
> slave/master relationship if one of them is rebooted/powered off
> manually (e.g. pressing power on mvp actually turns it off, which
> would leave the exstreamer locked out)
This is one area I'm kind of concerned about as I've one Rio player
located in the garage (intended to always be slaved) feeding
speakers in the living room of the house (wiring/walls dictated
this...) Alternately, it would be located out of reach so I'm
counting on stable control of the player remotely including a way to
reboot it from the web interface.

Tony, the stock Rio code has a function to do a hard reboot if you
hold the power button for 3-5 sec (i.e. it will reload the firmware
from the network). Is that something you could also emulate in the
tRio code? I've had to resort to unplug/plug for various issues and
it's a bit annoying. Just a thought.

Thanks for your ear,
Tim





xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx