RE: Re: xPLMediaNet Devices Controlling Devices - important please

["Tony Tofts" <tony@xxxxxxxxxx>]

Hi Tim,

> 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.)

I think this needs some clarification

The master/slave relationship is purely for remote control of a device, in
the same way as the web interface is.

I didn't want to add loads of new code to the clients, for a facility that
won't be used much. The way I've done it is very simple (and imo very
slick)
in that a client uses pointers to it's ir process and menu display.
Therefore when a device becomes master it points it's ir process at the
slave, and forces the slave to set it's display menu process at the master.
Simplicity!

Since volume control is normally only available on the rio front panel when
it's not in a menu (as the same control navigates the menu) then volume
control isn't an issue as when the device isn't in a menu it isn't a slave.

However, as you point out it may be necessary to change volume at the
client
but it may be in slave mode at the time. So I'll make sure that the 'menu'
function is available locally at all times. This will allow a user to exit
slave mode at the slave end.

> I suppose this would be acceptable, but kind of funky. How
> often does this really occur? Good to anticipate the issue. :-)

MVP=10, rio=4, slim=2, exstreamer=4, others=?

> > 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.

Not sure what you mean here, perhaps confusion over what master/slave does?
See above.

> 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.

Again, see above. This is in no way a synch system. This is about web like
remote control?

> Seems odd. I would expect the Slave device to display
> whatever it is doing...

Just simplicity. If the slave isn't in a menu it isn't a slave.

I can make it pick up the existing menu position of a slave if preffered
though (with music selection being the default if it's not in a menu)

> 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.

This is pretty much resolved, when a device is rebooted (from the menu) the
relationship is broken. When a device reboots after another problem again
the relationship is cleared.

> 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.

This would only be available if it becomes a function of riot.

Though button bounce is an issue, so I may be able to track the power
button
being held down once I have some anti-bounce code in place.

Regards
Tony




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