[mythtv] Ticket #7847: After resume from long S3 sleep, scheduling via EPG isn't refreshed on EPG

[Warpme]

On 2/2/10 7:35 AM, MythTV wrote:
> #7847: After resume from long S3 sleep, scheduling via EPG isn't refreshed on EPG
> ------------------------------+---------------------------------------------
>   Reporter:  warpme@…          |       Owner:  ijr
>       Type:  defect            |      Status:  infoneeded_new
>   Priority:  minor             |   Milestone:  0.23
> Component:  MythTV - General  |     Version:  0.22-fixes
>   Severity:  medium            |     Mlocked:  0
> ------------------------------+---------------------------------------------
>
> Comment(by anonymous):
>
>   This will happen any time the BE uses the event socket while the FE is
>   asleep; the length of sleep time is irrelevant.  E.g. if one FE updates
>   the schedule while another is sleeping, the BE tries and fails to update
>   the sleeping FE, resulting in the BE closing its side of the event socket.
>   When the FE wakes up, it doesn't know that the BE has closed the
>   connection, so the FE forever listens on the dead socket.
>
>   [23397] will help, and with some interval tuning, it could be made to work
>   reasonably well.  But as Mark alluded, an application-level heartbeat on
>   the event socket from the FE would be a more complete way to address this
>   issue.
>
>    
Hi,

Thx for quick response.

I applied this patch for testing purposes.  Tested on 0.22-fixes 23426 + 
ticket 7836

Results:
After resume from sleep, with sleep period longer than 
keep-alive-time+(keep-alive-intrval*keep-alive-probes), user sees dialog 
"backend connection lost".
So I would say changset 23397 is serious regression for setups with 
separated FE & BE and when user is using S3 on FE.

I think it is expected result, as keep-alive is closing all TCP 
connections between BE-FE when sleep time is longer than 
keep-alive-time+(keep-alive-intrval*keep-alive-probes).
 From this perspective 23397 is serious regression as in my case user 
sees "Backend connection lost" and when Esc is pressed - FE crashes 
(this crash is not result of this patch. I have it also i.e. when I kill 
BE when FE sleeps. Resuming FE and starting doing ordinary operations, 
like recording selection, causes FE crash).

Anyway - I think scenario with separated BE and FE and using S3 o FE 
needs rethinking. I would consider i.e. using TCP connections initiated 
from FE to BE, but  long, persistent connections initiated from BE to FE 
might be switched from TCP to UDP.
As UDP is stateless - maybe it will help solve problem ?
TCP Keep-alive solution is definitely bad idea IMHO.

Regarding heart-beat approach - I think it will be not so easy, as we 
will need in BE to discover FE in sleeping state.
Without it, BE will falsely threat slipping FE as dead FE.
I think simpler approach will be approach with keeping all FE->BE 
connections as always-on, and changing persistent BE->FE connections to 
state-less type (UDP)

br



-------------- next part --------------
A non-text attachment was scrubbed...
Name: warpme.vcf
Type: text/x-vcard
Size: 89 bytes
Desc: not available
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100203/228a2612/attachment.vcf>