[mythtv] Ticket #7847: After resume from long S3 sleep, scheduling via EPG isn't refreshed on EPG
Warpme
warpme at o2.pl
Wed Feb 3 08:35:56 UTC 2010
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>
More information about the mythtv-dev
mailing list