[mythtv] Reducing frontend startup time

[Dan Wilga]

Revisiting a very old thread, for the benefit of anyone else following 
my problem with LIRC losing its connection upon wake from sleep...

On 1/12/16 12:22 AM, f-myth-users at media.mit.edu wrote:
>      > Date: Mon, 11 Jan 2016 09:43:03 -0500
>      > From: Dan Wilga <mythtv-dev2 at dwilga-linux1.amherst.edu>
>
>      > It's something to do with the TCP connection between the frontend and
>      > the backend getting dropped if the frontend machine is in S3 idle for
>      > too long. (Note that I said UDP in my original post; I just verified
>      > that it is TCP.)
>
> That seems reasonable.  There are several ways this might happen,
> and you may be able to configure them.  You may also be able to use
> wireshark on the non-sleeping end, or a hub (or a smart switch that
> can clone ports, but not a dumb switch) between them, to see what
> the actual traffic looks like.
>
> First, one end or both ends may be using TCP keepalives.  (ssh will
> do this by default, for example, but you can turn it off.)  This will
> typically cause your connection to die in about two hours, plus some
> extra fuzz.
>
> Also, assuming you turn that off, there are a couple different
> timeouts that affect how long it takes a connection to die if you've
> tried to send a packet to the other end and it hasn't been acknowledged.
> You can configure how many retries it takes before the conn fails.
> I have no idea if you might have even a single outstanding unacked
> packet in either direction when your host sleeps, but it's possible.
>
> (In other words, keepalives send traffic when there hasn't been any
> traffic in a long time, and kill the connection if the keepalive
> doesn't get acknowledged.  TCP timeouts notice if there -is- traffic
> but the other end doesn't seem to be answering it.)
>
> This assumes that taking the frontend out of sleep doesn't cause the
> network stack to reset its network in some way, of course, which will
> kill connections at its end regardless.  And that things like arp
> don't forget mappings from Ethernet MAC addresses to IP addresses.
>
> If you'd like some pointers as to which values you might try frobbing
> with, say so, though I'm unclear whether either end can be configured
> to not use keepalives if it is, because I don't know what software is
> actually at either end of the TCP connection.  It might be a better
> idea to explicitly reinitialize the TCP connection at both ends when
> coming out of sleep, if you can arrange that.
>
In the last few days, work has progressed on this issue:

   https://code.mythtv.org/trac/ticket/12229

and the patch at comment 21 works for me.