[mythtv-users] BackEnd Unresponsive After Deleting Recording 0.23.1 w/ new SBE

[James Crow]

On Thu, Sep 16, 2010 at 3:56 PM, Khanh Tran <khanh at khanh.net> wrote:
>
>
> On Tue, Sep 14, 2010 at 8:33 AM, James Crow <crow.jamesm at gmail.com> wrote:
>>
>> Today as a second test I shutdown my SBE and will verify that the MBE
>> returns to normal.
>>
>
> I've tried this and can report that my MBE dies regardless of the SBE
> running or not.  I used to think it was the end of a commflagging job or
> mythtranscode, but it will happen generally at the end of a
> recording/beginning of a new one when the database is doing work switching
> recordings.  I get the following in the MBE:
>
>
> 2010-09-15 23:30:34.254 ProgramInfo(): Updated pathname '':'' ->
> '1012_20100915230000.mpg'
> 2010-09-15 23:30:34.266 JobQueue: Commercial Flagging Starting for News 12
> Westchester recorded from channel 1012 at Wed Sep 15 23:00:00 2010
> 2010-09-15 23:30:34.334 Using runtime prefix = /usr/local
> 2010-09-15 23:30:34.339 Using configuration directory = /home/mythtv/.mythtv
> 2010-09-15 23:30:34.342 Empty LocalHostName.
> 2010-09-15 23:30:34.344 Using localhost value of tv
> 2010-09-15 23:30:34.348 Testing network connectivity to '192.168.1.3'
> 2010-09-15 23:30:34.365 New DB connection, total: 1
> 2010-09-15 23:30:34.373 Connected to database 'mythconverg' at host:
> 192.168.1.3
> 2010-09-15 23:30:34.374 Closing DB connection named 'DBManager0'
> 2010-09-15 23:30:34.380 Connected to database 'mythconverg' at host:
> 192.168.1.3
> 2010-09-15 23:30:34.385 ProgramInfo(): Updated pathname '':'' ->
> '1012_20100915230000.mpg'
> 2010-09-15 23:30:34.437 MythContext: Connecting to backend server:
> 192.168.1.3:6543 (try 1 of 1)
> 2010-09-15 23:30:41.442 MythSocket(8178b48:11): readStringList: Error, timed
> out after 7000 ms.
> 2010-09-15 23:30:41.443 Protocol version check failure.
>                         The response to MYTH_PROTO_VERSION was empty.
>                         This happens when the backend is too busy to
> respond,
>                         or has deadlocked in due to bugs or hardware
> failure.
> 2010-09-15 23:30:41.445 MythContext: Connecting to backend server:
> 192.168.1.3:6543 (try 1 of 1)
> 2010-09-15 23:30:43.866 AFD: Opened codec 0x817df30, id(MPEG2VIDEO)
> type(Video)
> 2010-09-15 23:30:43.872 AFD: codec AC3 has 2 channels
> 2010-09-15 23:30:43.873 AFD: Opened codec 0x8180a90, id(AC3) type(Audio)
> 2010-09-15 23:30:48.461 MythSocket(817e880:11): readStringList: Error, timed
> out after 7000 ms.
> 2010-09-15 23:30:48.467 Protocol version check failure.
>                         The response to MYTH_PROTO_VERSION was empty.
>                         This happens when the backend is too busy to
> respond,
>                         or has deadlocked in due to bugs or hardware
> failure.
> 2010-09-15 23:38:38.683 AutoExpire: CalcParams(): Max required Free Space:
> 3.0 GB w/freq: 15 min
> 2010-09-15 23:38:38.736 Expiring 731 MBytes for 1012 @ Tue Sep 14 23:00:00
> 2010 => News 12 Westchester.  Too many episodes, we only want to keep 1.
> 2010-09-15 23:38:38.742 Expiring 484 MBytes for 3050 @ Tue Sep 7 23:00:00
> 2010 => The Daily Show With Jon Stewart.  Too many episodes, we only want to
> keep 5.
>
> By the way, the ONLY thing the backend will do after this MYTH_PROTO_VERSION
> error is AutoExpire and mythfilldatabase seems to work (mine runs sometime
> between 1AM and 5AM).  Frontends, slave backend, mythweb and the master
> backend itself won't do anything else until I restart the MBE process.  This
> happens about every 3 to 5 days or so and have only been an issue for me
> since around r25084.
>
> I'm going to start my mythbackend logging with "-v network,extra,socket" as
> suggested and report back next time there's an issue.
>
>

I submitted a ticket to trac and it was closed saying it was a
duplicate of 7608 or 8526. Ticket 7608 is waiting on logs, but 8526
has a couple of patches for deadlocks. If you have some logs maybe you
could attach them to 7608. I was able to get one of the two patches
from 8526 to apply to 0.23.1-26231, but the second one does not. I ran
my MBE with the one patch applied yesterday and it still experiences
the same problem. I am now trying to learn how to find a deadlock and
see if I can get more/better logging. I wish I knew some C++.

Cheers,
James