[mythtv-commits] Re: Ticket #617: Allow non-blocking client connections

MythTV mythtv at cvs.mythtv.org
Tue Nov 8 17:05:52 EST 2005


#617: Allow non-blocking client connections
-----------------------------+----------------------------------------------
 Reporter:  gnassas at mac.com  |        Owner:  gnassas at mac.com
     Type:  patch            |       Status:  reopened       
 Priority:  minor            |    Milestone:  0.19           
Component:  mythtv           |      Version:  head           
 Severity:  medium           |   Resolution:                 
-----------------------------+----------------------------------------------
Changes (by gnassas at mac.com):

  * resolution:  wontfix =>
  * status:  closed => reopened

Comment:

 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.

-- 
Ticket URL: <http://cvs.mythtv.org/trac/ticket/617>
MythTV <http://www.mythtv.org/>
MythTV


More information about the mythtv-commits mailing list