Opened 5 years ago

Closed 3 years ago

Last modified 18 months ago

#12229 closed Bug Report - General (fixed)

After S3 sleep or FE Idle event connection is dead

Reported by: warpme@… Owned by: Peter Bennett
Priority: minor Milestone: unknown
Component: MythTV - General Version: Master Head
Severity: medium Keywords: S3 sleep event connection
Cc: Ticket locked: no

Description

According to #7847 this seems to be regression.

Scenario to reproduce: 1.Start system, launch FE. 2.Enter FE into Idle. 3.Enter system into S3 sleep for some time (i.e. 1h) 4.Resume system form S3 sleep. 5.Quit FE from Idle. 6.Go i.e. to EPG. 7.Try to schedule show. 8.Event connection seems to be dead as there is no state refresh on EPG. 9.Restart FE - all works OK.

Attachments (2)

20170408_sleepfix.patch (3.0 KB) - added by Peter Bennett 3 years ago.
Possible fix for sleep problem
20170410_sleepfix.patch (3.3 KB) - added by Peter Bennett 3 years ago.
Patch with code for LIRC added

Download all attachments as: .zip

Change History (15)

comment:1 Changed 3 years ago by Peter Bennett

Owner: set to Peter Bennett
Status: newassigned

comment:2 Changed 3 years ago by mythtv@…

Note that I experience a similar problem with the frontend's communication with a LIRC server upon resume from sleep. Perhaps whatever method is used to ensure the backend connection's restoration could also be applied to the LIRC socket.

comment:3 Changed 3 years ago by Peter Bennett

I cannot recreate this.

I tested this on master, with frontend in S3 sleep for 36 minutes. After resuming, I can schedule shows and it is reflected in the grid. Do you have any way of forcing this to happen? For testing it would be preferable not to have to wait for an hour or two for each test.

What I do, is terminate frontend if the system goes to sleep. I have a systemd unit pre-sleep that includes the command "killall mythfrontend". After resuming, you log on again to start the frontend. WAF is fine with this :)

comment:4 Changed 3 years ago by warpme@…

Peter, I'm not sure about this but I believe to trigger issue we need to manage tcp stack to break existing connections by having long enough sleep. In my case I need few hours to catch issue. Pls try with 2h - and if You will be not able to catch - pls try with 12-24h of sleeping.

Changed 3 years ago by Peter Bennett

Attachment: 20170408_sleepfix.patch added

Possible fix for sleep problem

comment:5 Changed 3 years ago by Peter Bennett

Please test the attached patch. This forces a reconnect of the backend after any sleep of more than 60 seconds. You will see some messages on the screen about backend offline and backend online when coming out of sleep. If this works I can use a longer duration than 60 seconds if necessary.

This patch does not address lirc. Let's see if this works first.

comment:6 Changed 3 years ago by warpme@…

Peter, excellent work! I put this on 3 production systems and dead event connection issue seems to be resolved. I'm testing by following procedure:

1.put into sleep

2.wait few hours

3.resume

4.just after resume i'm entering guide and press REC to schedule recording. If event connection is alive - user should see visual feedback on guide when BE schedules recording. With Your patch I see visual feedback on guide so control connection seems to be alive after sleep.

Looking on fe log I frequently see following:

2017-04-09 18:54:11.047319 I Received notification \'Konto E-Mail:\', timeout 8
2017-04-09 20:01:34.334545 N MythCoreContext::connectionClosed(): Event socket closed. No connection to the backend.
2017-04-09 20:01:34.810830 I MythCoreContext::ConnectCommandSocket(): Connecting to backend server: 192.168.1.254:6543 (try 1 of 1)
2017-04-09 20:01:48.625222 I New DB connection, total: 1
2017-04-09 20:01:48.815823 W Container \'guidegrid\' is missing child \'longdatetext\'
2017-04-09 20:02:00.563011 E DB Error (UPDATE/INSERT record):
Query was:
INSERT INTO record SET type = ?, search = ?, recpriority = ?, prefinput = ?, startoffset = ?, endoffset = ?, dupmethod = ?, dupin = ?, filter = ?, inactive = ?, profile = ?, recgroup = ?, recgroupid = ?, storagegroup = ?, playgroup = ?, autoexpire = ?, maxepisodes = ?, maxnewest = ?, autocommflag = ?, autotranscode = ?, transcoder = ?, autouserjob1 = ?, autouserjob2 = ?, autouserjob3 = ?, autouserjob4 = ?, autometadata = ?, parentid = ?, title = ?, subtitle = ?, season = ?, episode = ?, description = ?, category = ?, starttime = ?, startdate = ?, endtime = ?, enddate = ?, seriesid = ?, programid = ?, inetref = ?, chanid = ?, station = ?, findday = ?, findtime = ?, findid = ?, next_record = ?, last_record = ?, last_delete = ?, avg_delay = ? ;
Bindings were:
:AUTOCOMMFLAG=false, :AUTOEXPIRE=true, :AUTOMETADATA=true, :AUTOTRANSCODE=false,
:AUTOUSERJOB1=false, :AUTOUSERJOB2=false, :AUTOUSERJOB3=false,
:AUTOUSERJOB4=false, :AVGDELAY=100, :CATEGORY="film", :CHANID=11104,
:DESCRIPTION="Po stopnieniu wszystkich lodowcĂłw Ziemia zmienia się w wielki ocean. Ludzie, ktĂłrym udało się przetrwać kataklizm, mieszkajÄ
 na łodziach i sztucznych atolach. NiektĂłrzy z ocalałych wierzÄ
 w istnienie mitycznego suchego lÄ
du. Ĺťeglarz (Kevin Costner) naleĹźy do pierwszego pokolenia modyfikowanych genetycznie ludzi wyposaĹźonych w skrzela. Odrzucony przez zwykłych śmiertelnikĂłw, Ĺźyje samotnie na łodzi. Pewnego dnia zawija do jednej ze skonstruowanych sztucznie pływajÄ
cych osad. W tym samym czasie pojawiajÄ
 się tam oceaniczni piraci, Smokersi, dowodzeni przez bezwzględnego Deacona (Dennis Hopper). NapadajÄ
 na mieszkańcĂłw i ograbiajÄ
 ich. W ogĂłlnym zamieszaniu Ĺťeglarzowi udaje się uciec z pomocÄ
 pięknej Helen (Jeanne Tripplehorn) i jej podopiecznej, Enoli (Tina Majorino). Razem podÄ
ĹźajÄ
 w dalszÄ
 drogę. Legenda głosi, że dziewczynka ma na pleca
2017-04-09 20:02:26.445855 I Received notification \'TVN24 HD\', timeout 10

It this expected thing?

comment:7 Changed 3 years ago by Peter Bennett

The database error does not look good. It does not say why it failed. It is creating a new recording rule. If you say that it successfully created the recording rule, perhaps this error is not important.

comment:8 in reply to:  2 Changed 3 years ago by Peter Bennett

Replying to mythtv@…:

Note that I experience a similar problem with the frontend's communication with a LIRC server upon resume from sleep. Perhaps whatever method is used to ensure the backend connection's restoration could also be applied to the LIRC socket.

There is a method built in for restarting the lirc support

kill -SIGUSR2 24006

where 24006 is the process id of mythfrontend.

I can build it into the logic for detecting wakeup from sleep. I do not currently have an lirc setup so I cannot test it. Are you able to test a patch if I create one?

Changed 3 years ago by Peter Bennett

Attachment: 20170410_sleepfix.patch added

Patch with code for LIRC added

comment:9 Changed 3 years ago by Peter Bennett

Please test the attached patch 20170410_sleepfix.patch​ to see if it fixes the lirc problem.

comment:10 Changed 3 years ago by mythtv@…

Thanks for all your work on this, Peter.

I have already taken the time to regenerate my personal rpms using the first (database) patch, so I'm going to try just that one first. If that fails, I'll try the LIRC version. Due to the length of time needed to reproduce the problem, this may take a day or two. Please leave this ticket open for the time being.

comment:11 Changed 3 years ago by mythtv@…

Overnight I tried the database-only version of the patch, but it didn't help. So I tried the one in comment 21 and it worked! I left the computer in sleep for 8 hours and when I came back to it this morning it resumed right where I left off.

Of course, I now realize that this will have an effect upon my family's viewing habits, given that turning the TV on will put them back to the last place where the previous person was--even if that's in the middle of a watching a recording. Given that and the fact that we PIN-protect some recording groups, I'm going to look into using the API to return to the main menu when waking from sleep.

So please consider this one RTBC as far as I'm concerned.

comment:12 Changed 3 years ago by Peter Bennett <pbennett@…>

Resolution: fixed
Status: assignedclosed

In ed3b8d4be9c34ff878b4c68d746e8f119a6fe3c8/mythtv:

Frontend reset socket connections after resuming from suspend

Fixes #12229

comment:13 Changed 18 months ago by Peter Bennett

Owner: changed from Peter Bennett to Peter Bennett
Note: See TracTickets for help on using tickets.