What *should* happen when a PPC is waking up?

[avid]

Hi,

Opinions wanted.

My NetRemote PPC sleeps a lot. And when it resumes, it takes about 5 seconds to establish a WiFi connection with the PC.

The question is what should happen to the actions arising from button presses in that first 5 seconds? There are two obvious alternatives:
1) Send the action anyway and ignore any networking errors, so that the action becomes a no-op, but the button press returns quickly.
2) Repeatedly retry the action on a networking error for some timeout (say 10 seconds), which means that the button will eventually do what you asked. But meanwhile, the PPC screen locks up (with the button “pressed”) until there is a connection.

This choice affects the behaviour of most of my own drivers (Zoom, WMP9, PlayPick & DigiTvEPG). But it also has relevance to Ben’s Girder and MediaBridge drivers. More important than getting it “right” for any one driver is getting it consistent.

My drivers currently choose option (1) above. I believe (but am not totally sure) that Ben’s do the same. But I am beginning to think that option (2) – blocking until the button press “works” remotely – might be a better choice.

Opinions anyone?

Brian

[Jlee]

This is a WAF issue for me. I'd like to make my CCF more intuitive and display some message or indicator when there is no WiFi signal available. I'd actually prefer option 1 as you know where you are with that. I don't like the idea of an action occuring 10 seconds after you requested it.

[avid]

Another problem with the existing option (1), which we may want to take into account, is that if a remote action is combined with a panel jump, then the action may do nothing, but NR will jump to a panel that might might only make sense if the remote action had worked. One particular example is when the button invokes Girder to start a program on the HTPC and then jumps to a NR panel to control that application, which might not actually be running.

Brian

[Promixis]

Brian,

I have often thought about this as well.

I think the most important piece is that the user know what is going on. I see that when people use NR at my house and they get button happy before NR reconnects. I think we need someway to let the user know what is happening....


The other confounding factor is DirectIR which works right away after a resume. This might be in the middle of a macro with tcp/ip.

[Jlee]

I think we need someway to let the user know what is happening....

I agree entirely with this comment. That's exactly what I've been trying to do (though I gave up before doing a lot of investigation). Ideally I'd have a message displayed over the top of everything explaining that there is no WiFi connection though I appreciate that there's a lot to think about in implementing this.

With MC I can handle this really intuitively because we have the MP.LinkActive variable. I'd love to have, Girder.LinkActive and WiFi.LinkActive variables too.

[avid]

With MC I can handle this really intuitively because we have the MP.LinkActive variable. I'd love to have, Girder.LinkActive and WiFi.LinkActive variables too
The problem is that NR does not of itself talk to an HTPC. The driver instances do, and each driver talks to a different piece of server software on the HTPC. Now we *could* argue that if *any* driver can talk to the HTPC, then *all* drivers should be able to.

But there is no one driver which is present on all setups. Girder might not always be there (e.g. for LE) and MC/MediaBridge might not be there - I for one don't use it.

So ... we could argue for three parallel features, leaving it to the CCF to choose what is appropriate:
1) Each connected driver to have (by convention) its own LinkActive variable (we already have MC & ZP).
2) Girder to have a new "block until connected" action that could be used in button action sequences suchas when starting a new application.
3) A global preference, to be handled by all drivers, by which the users can switch on blocking until a connection is restored.

What do people think of this as a proposal? In particular, what do you think Ben?

Brian

[Wilhelm]

Well guys, you can open a dialog "waiting for the network to come up" or something like this, but it should also vanish, a soon as the connection is established.
But for buttons that execute macros it is an absolute no-no if you begin sending i.e. IR codes totally asynchronous a soon as the network comes up, leaving out some and sending some others.
It is hard enough to get macros to work reliably, but if you can't be sure what is sent and what is not this all goes out of the window.
Sending remote codes probably is the most critical action. I think at least those requests should have a queue or buffer that assures everything is sent in sequence and that nothing is lost.
For other drivers it might be not so important if a request is sent once or twice and what time elapses until the answer arrives.

[danward79]

I would say let the user know what is happening.

[Mastiff]

The warning is the best way in my opinion. It should be used with the coming function to put a frame on top of all windows, so that you can choose to have one frame that will cover everything else with a message you write yourself, sort of like the link active with MC. Anyway, for me it's possible to simply use the MC bit, since I always have that active on the network. But what about having a small app, something like the MediaBridge, to handle that? Or even build it into media bridge, so you'll always know if the link is active?

[avid]

I'm hearing lots of different ideas here.

I think we need to distinguish between what simple enabling mechanisms are needed in NR or standard drivers, and then what could or should be achieved in the CCF or LUA.

My short-term recommendation and request to Ben is to add two simple things to the Girder driver.
1) A Girder.LinkState variable. This would be set to "0" initially and on Resume and set to "1" in SocketConnected..
2) A new Girder action, that blocks until Girder.LinkState is non-zero or for 10 seconds (whichever comes first).

Both of these are trivial additions, with no backward compatability implications. [Ben, I'll do it for you if you want].

Then, using those, a number of us can experiment with the different ways of handling the problem in the CCF and LUA. Only by this experimentation will we find something with an OK WAF. And we may end up with two or more different acceptable behaviours.

What do you think Ben? Anyone?

Brian

[Wilhelm]

Perhaps something like this?

All unidirectional outputs (IR, WOL, etc) get buffered until they are definately sent, all bidirectional communications (Girder, Mediabridge, etc) get a state variable and a blocking mechanism. Nevertheless I cannot inagine what good would it do to keep communication up when a specific plugin has no connection. I think NR should handle that internally. If anyone wants to popup a message, he can do that in the lua checking the state variables.

Could this be a way to go?

[avid]

all bidirectional communications (Girder, Mediabridge, etc) get a state variable and a blocking mechanismYes - this is what I have asked for to enable some user-meaningful behaviour. Actually, for most purposes, a blocking mechanism in Girder alone is enough.

All unidirectional outputs (IR, WOL, etc) get buffered until they are definately sentThis makes sense as long as there is a reasonable timeout (about 10 s). But this is a real change to what happens now and would not be backwardly compatible. Would it break any CCFs?

If anyone wants to popup a message, he can do that in the lua checking the state variablesAbsolutely! With suitable simple support from NR and drivers, you can make the CCF and LUA do just what you want.

Brian

[Jlee]

If anyone wants to popup a message, he can do that in the lua checking the state variables.

The problem is that when the PPC awakens and NR is already open (but no longer connected) won't the state change only occur when the WiFi connection is resumed? If so that's too late - you need a pop up message as soon as the ppc wakes up.

[avid]

If anyone wants to popup a message, he can do that in the lua checking the state variables.

The problem is that when the PPC awakens and NR is already open (but no longer connected) won't the state change only occur when the WiFi connection is resumed? If so that's too late - you need a pop up message as soon as the ppc wakes up.
No - it's a lot better than that. The proposed Girder.LinkState variable will be set to zero within about half a second of waking up. LUA can notice this and "do something". When the connection is established (after 5 seconds or so) then the Girder.LinkState variable will be set to one.

I already do something similar in the Zoom driver, setting certain variables to "neutral" values while waiting to reconnect. That works well for me.

Brian

[Wilhelm]

As I said, this should be handled internally by NR. A state variable only makes sense, if it is 100% accurate.
And JLee you only need a popup, if you execute an action. I find it rather useless if NR reports an "transmission error" if nothing is to be transmitted, right?

@ Brian
If a timeout happens, all buffered information needs to be discarded. Otherwise you would have an undefined state. (concerning macros) This means, if you have an action that send 3 IR codes and afterwards switches to another panel all 4 actions would have to be discarded.

[Promixis]

Great ideas....

So lets look at some scenarios....

1. NR Music. The default CCF displays a message box that the connection to the current host is blah blah... and that box goes away when the link is good.

I think this is fine and its entirely setup by the CCF so the user can configure it.

BUT what if the CCF doesn't check the link? Should NR display an error message when the user presses on a button when there is no link?

2. Direct IR. No need to have any message.

3. Girder. I like Brian's idea with functionality similar to MB.

4. Mixed CCF's....

This is where I think things can get difficult. Macros that utilize several different plugins +/- jumps.....

Should NR block the button press if any of the "links" are broken?

Ie. say I have a macro for selecting the HTPC to play music...

Direct IR to receiver to select HTPC.
NR to Girder to Projector to select HTPC.
NR to MB to start player.

How would this work if one link is down (ie. Girder).

Error message?
Block?
Send commands it can?

[Rob H]

Error message?
Block?
Send commands it can?

Definitely not the third one.

I don't think anyone has suggested a call to a LUA function (if defined) called something like OnLinkFailure(pluginId) - that way you could leave it up to the CCF designer to decide what to do if e.g. Girder can't be located. If the function returns nil then block all the commands, if it returns anything else then perhaps you could send whatever commands it can. It would be useful to be able to identify the plugin from the pluginId from LUA, and possibly also get the IP address or hostname.

[avid]

Mixed CCF's....

This is where I think things can get difficult. Macros that utilize several different plugins +/- jumps
There are different degrees of difficulty. By far the most common situation is where the PPC talks to a single HTPC. And the most common problem is that the WiFI connection takes 5 seconds to be established. But in this case, a connection to any one driver (e.g. Girder) can be treated as a connection to any.

With the new Girder "blocking action" my intention would be to block at the start of the actions of my top-level buttons which use Girder to invoke an application and then jump to that application's NR panel. For some of the other actions (usually those that don't jump) I might choose just to gray the button out (via its state) when there is no connection and allow the action to do nothing. Or for others I might use some LUA to play a sound.

Beyond these common cases, I can see problems when controlling multiple machines - e.g. multiple Girder driver instances. A single Girder.LinkState variable would then not be enough, although the blocking action would still work.

But for now, my recommendation would be to keep it simple to start with - using the two proposed simple Girder driver enhancements. In that way, the Girder connection (or the MC connection) can be used to determine if WiFi is connected. That will cope with 99% of the current problem cases.

Brian

[Wilhelm]

I suggest we distinguish between a server not running and the WiFi connection being down?
In the first case, there may be different outcomes, the second one demands a stop and wait in all cases (I think).
And the more I think about it, I would prefer that every plugin that is configured should have connected to the appropriate server before anything happens (at least as a default). I cannot imagine a ccf that would work reliable, if any of the used plugins/servers don't run or work.

[Ben S]

Great discussion, folks. Thanks for starting it, Brian.

Beyond Brians suggest (which I complete agree with - of having a Girder.LinkActive), the best way to handle this (if required) is to ping the machine you've identified as the default host, and have a "DefaultHost.Active" variable, which could be handled in your own way. It needs to be this way, because someone like Tor may have his default host as one of his home computers, but be in his truck at the time, so it can't disable all actions.

The problem with halting all actions until alive is that each action isn't aware of the action group it's part of. I had to do some tricks to work around IR issues with macros by counting IR actions first, but it would be tough to check each plugin for being alive for each action that uses it before sending any actions. Know what I mean?

[Wilhelm]

Yes, I think I suffered from lack of imagination. ;-)

[avid]

Ben,

Can you also add the "blocking action" to the Girder driver at the same time.

Its implementation will be trivial - add a manual-reset Event, whose set/reset state mirrors the new Girder.LinkState variable. Then the action is simply to wait on that event with a timeout (either a fixed 10 seconds or you may want to encode it in the IR name).

Thanks

Brian