Allow non-blocking client connections

[gnassas@…]

There's an issue with the (terrific & long overdue) new mythwelcome program in that it overrides the BE process' established power on/off management through the blockSDWUwithoutClient and idleTimeout settings. Essentially mythwelcome suppresses mythfrontend when the PC comes up for a recording (allowing normal BE power management to function) and launches mythfrontend in any other case. The idea is you've powered up either to record something or because the user has pressed poweron to watch a show.

That's true when your entire myth setup consists of one FE/BE but it falls apart when you add one or more FE-only clients to the mix (as I recently did). Now when a remote client powers up the FE/BE (using WOL) mythwelcome sees that no recording is pending and starts up a local FE process. That process keeps the FE/BE from shutting down the PC even after the remote FE has disconnected.

One way to address this is to never autostart mythfrontend on the FE/BE box. Instead, the FE/BE should rely on the user clicking the "Start Frontend" button. This sounds fine except that during its startup mythwelcome briefly identifies itself as a FE process and trips the BE process into starting its poweroff countdown. If, like me, you're in the habit of pressing the power button on your FE/BE and walking off to get a snack you'll return to find your PVR has come up, waited a bit and then shut itself off.

I propose giving mythwelcome a way to connect to the BE without being counted as a blocking connection for power management purposes. In more direct terms I propose adding a flag to MythContext::ConnectToMasterServer? where clients can say they're making a non-blocking connection.

I had a lot of trouble writing this up as it's an arcane problem so it may merit some discussion. However I do believe this is the correct approach since it moves power management back into the BE. The way mythwelcome is currently written it takes over that job.

Patch to follow.

[gnassas@…]

the bulk of the changes

[gnassas@…]

mythweb need to know about the protocol change

[Isaac Richards]

I fail to see how this patch does anything beyond what the existing 'BLOCK_SHUTDOWN' command does.

[gnassas@…]

On 8-Nov-05, at 3:20 PM, MythTV wrote:

I fail to see how this patch does anything beyond what the existing 'BLOCK_SHUTDOWN' command does.

There is no way for a combined FE/BE to know when to appropriately use the block shutdown command. All mythwelcome knows is if a recording is about to start. That's good enough when all you have is one FE/BE system but when FE-only machines enter the mix it isn't enough info. You'd have to go through a sequence like this:

How did I power up? Via RTC: A recording is happening, don't block so I can shutdown at end of recording. Via power button: User wants to watch recordings, start FE which will block shutdown. Via Wake-On-Lan: A remote FE wants to watch, don't block so BE will shutdown when remote host disconnects.

None of those can be directly detected although the RTC one can be inferred by seeing if a recording is about to start. The WOL case is problematic. You might be able to infer it by asking did I not power up via RTC and is there another client freshly connected but that's pretty brittle. So, when a remote FE starts the FE/BE through WOL it will be assumed as being due to the power button, the FE will be started and the FE/BE will stay up indefinitely.

Adding that one argument to ANN Playback gives each client the opportunity to say "I'm important, don't go away" or "I'm a passive scoreboard app, never mind about me." That simplifies things a lot and takes out all the guessing.

Of course, if there's a better way... but I've put some thought into this and I've been running it here and it's fine. I don't see how you'd reliable handle this situation any other way.

• George

P.S. I'm reopening this but I'm not sure if that's the proper thing to do so no impertinance intended if it isn't.

[Isaac Richards]

But that extra argument to announce does exactly the same thing as the block_shutdown/allow_shutdown commands. All you're doing is moving that exact same functionality into the announce command, which I don't see the point of.

[gnassas@…]

> But that extra argument to announce does exactly the
> same thing as the block_shutdown/allow_shutdown commands.

Not true. The extra argument lets the BE know the nature of the connection before it clears the blockShutdown flag in Scheduler::RunScheduler?. The code I'm looking at is this:

            // we release the block when a client connects
            if (blockShutdown)
                blockShutdown &= !m_mainServer->isClientConnected();
            else
            {
                // find out, if we are currently recording (or LiveTV)
                bool recording = false;

That flag is the key to blockSDWUwithoutClient and there's currently no way for mythwelcome to connect without clearing it. Once that happens the PC is coming down toot sweet unless someone intervenes.

You're saying that somone is mythwelcome but, as I described in the earlier message, there's no possible way for it to figure out if the PC was brought up due to the power button, in which case it should block an idle shutdown, or due to WOL, in which case it's wrong to block as the BE should only stay up as long as the remote FE is connected.

I won't play games with the reopen checkbox but I do hope this makes it in. For sure it's a problem and it'd be good to get it out of the way before a release and millions (dozens?) of people trip over it like me.

• George

[anonymous]

Isaac,

Arguably "starting mythwelcome" has a different meaning than "stopping mythfrontend", right? Now look how the backend handles both occurences. Currently both FE an MW disconnections are handled the same, they trigger the countdown. To the BE they are the same, which is odd.

gnassas wants to create a type of (dis)connection that does not influence the power management state of the BE at all.

The block_shutdown / allow_shutdown commands tell that the existence of a particular connection should not stop the BE from doing a shutdown. It doesn't say anything about the the transition from "wait for FE" to the countdown state. So these commands can't be used to fix the problem.

[Isaac Richards]

That's not what the patch does, though. All it does is move the logic of the block_shutdown/allow_shutdown command into the announce command.

[paulh]

This patch doesn't look like it will work as intended to me anyway. What happens in the case where the combined FE/BE is started to record something. You still need mythwelcome to connect to the BE as a blocking client even if for only a few seconds so as to trigger the BE into shutting down when idle. Otherwise it will spin waiting for a client to connect because of the 'block shutdown before client connected' setting.

This is how it works now when starting up to record something. The following assumes you have the 'block shutdown before client connected' set to yes.

• the BE starts up , starts any pending recordings and spins waiting for a client to connect. It will wait in this condition forever until at least one client has connected even after all recordings have finished.

• mythwelcome starts up as a normal client (blocks shutdown from happening)

• the BE notices a client has connected and releases it blockshutdown flag. It is now free to shutdown when it becomes idle and there are no blocking clients connected.

• after a short period mythwelcome sends an ALLOW_SHUTDOWN command to the BE which tells it to ignore mythwelcomes connections when making the decision of whether to shut down when idle or not.

• after all recordings have finished and the BE becomes idle it shuts the computer down.

If you untick the 'Automatically Start Myth Frontend' setting on the combined FE/BE machine does everything work OK apart from the fact that if you start it up yourself and then leave it to boot up unattended when you come back to it you find it has shutdown again because the frontend didn't start automatically?

Maybe a better approach to the problem would be to make mythwelcome a little smarter as to when it sends the 'ALLOW_SHUTDOWN' command to the BE and/or when it starts up the FE automatically?

Paul

[gnassas@…]

Responding to Paul's comments:

 This patch doesn't look like it will work as intended to me anyway.
 What happens in the case where the combined FE/BE is started to
 record something. You still need mythwelcome to connect to the
 BE as a blocking client even if for only a few seconds so as to trigger
 the BE  into shutting down when idle. Otherwise it will spin waiting for a
 client to connect because of the 'block shutdown before client connected'
 setting.

This argument is incorrect. Review the following lines from Scheduler::RunScheduler?:

                // have we been started automatically?
                if ((startIter != reclist.end()) &&
                    ((curtime.secsTo((*startIter)->startts) - prerollseconds)
                        < (idleWaitForRecordingTime * 60)))
                {
                    VERBOSE(VB_ALL,
                            "Recording starts soon, AUTO-Startup assumed");
                    startupParam = "auto";
            
                    // Since we've started automatically, don't wait for
                    // client to connect before allowing shutdown.
                    blockShutdown = false;
                }

Later in the commentary:

Maybe a better approach to the problem would be to make mythwelcome a little smarter as to when it sends the 'ALLOW_SHUTDOWN' command to the BE

You can't implement this reliably without an argument to ConnectToMasterServer?. The problem is after crossing processes the connection request eventually comes down to MainServer::HandleAnnounce? where a PlaybackSock? is created and pushed onto the BE's playbackList. At that point it's visible to the loop in Scheduler::RunScheduler?. You can gamble on a quickie ALLOW_SHUTDOWN from MW right after the connect but you're in a race with the scheduler thread's loop and once that blockShutdown flag is cleared the horse has left the barn.

The only sure-fire way to do a non-blocking connection is to call PlaybackSock::setBlockShutdown before the push to playbackList. That implies a parameter to ANN Playback.

 and/or when it starts up the FE automatically?

I discussed this earlier. The problem is MW has no way to detect if 1) the PC has started due to the power switch in which case it should start the FE because the user wants myth, or 2) the PC has come up due to a WOL message in which case it should hang back with a local FE since you want the PC to come down naturally when the remote FE disconnects.

I started this because MW, as implemented in SVN, does not work in a mixed FE/BE FE-only environment. Try it yourself. This patch has been in production here for several days and I do a lot of recording and a lot of watching from both my FE and my FE/BE. I've seen nothing but success. Plus, I have fresher breath, whiter teeth, more women are attracted to me, I've made a fortune in real estate, my knives are sharper than ever, etc etc. What's not to like?

• George

[paulh]

OK you have convinced me it will work :) I was under the impression that the BE would not release the blockshutdown flag until at least one client had connected. It does indeed look like that does not apply if the BE was started to record something. I should have re-read though the code before speaking!

I'll patch my dev box with your patch and give it a try for a few day to make sure it does indeed work ok. I'm going to have to put together a frontend box from old components to try it with a remote frontend though.

Paul

[Isaac Richards]

If you do apply, it'd be nice to rework this to send the block/noblock bool on a separate line in the stringlist instead of in the same string as the rest of the ANN command. Shouldn't have to break compatibility that way.

[gnassas@…]

rework this to send the block/noblock bool on a separate line

I think the simplest way is to use a new ANN subcommand, maybe ANN Monitor, for non-blocking clients. In MythContext::ConnectServer? it'd check the block argument I added and either send an ANN Playback or ANN Monitor as appropriate. All the current ANN types would be the same from a client point of view although internally only the ANN Playback would leave the PlaybackSock? block flag as true, others would change it to false.

This is a good idea and requires touching only 4 files instead of the 8 the current patch does. When I started coding it seemed simpler to add the extra ANN argument but in retrospect that looks like a bad decision.

I doubt Paul has whipped together a spare client machine already so I'll rework the patch and submit it again by this evening.

• George

[gnassas@…]

simplified version of the change

[gnassas@…]

I've updated the patch in a new diff. The first two can be discarded. Because the existing ANN Playback signature has been preserved there are no changes required in mythweb. I'm back at r7600 so the protocol increment I added to my code has been obscured by another protocol change in current svn so if/when this gets committed that will have to be done as well.

-George

[paulh]

(In [7883]) Apply patch by George - gnassas (at) mac.com. Provides a cleaner way to make non blocking connections to the BE. Updates mythwelcome to use the new method to create its non blocking connection.

Changes by me to update mythlcdserver to use the same method to connect to the BE.

Updates the protocol to version 22.

These changes are basically the start to get mythwelcome working on remote frontends as well as combined FE/BE machines. There are still a few issues to fix though.

Closes #617