[mythtv-users] Really strange one...
b.taber at comcast.net
Fri Nov 18 22:16:02 UTC 2011
On Fri, 2011-11-18 at 16:28 -0500, Raymond Wagner wrote:
> On 11/18/2011 16:07, Matt Mossholder wrote:
> > On Fri, Nov 18, 2011 at 3:37 PM, Matt Mossholder
> > <matt at mossholder.com> wrote:
> > So, I decided to rebuild my backend with Scientific Linux
> > 61. I've enabled the epel, atrpms and atrpms-testing repos,
> > and installed mythtv-backend, mythtv-setup, mythtv-docs,
> > mythweb and mythtv-common.
> > After running mythtv-setup and mythfilldatabase, things
> > appear to be fine. Recordings are made and show up on disk.
> > However, any connection to the backend on port 6543 fails,
> > UNLESS it occurs before the initial run of the scheduler. I
> > haven't ever managed to get two connections to occur before
> > the scheduler run ( my timing isn't that good :), but any
> > connection that occurs after the scheduler runs fails,
> > because the backend never responds. By this I mean that the
> > connection is accepted, but no data is ever sent back, and
> > mythweb and/or find_orphans.py time out waiting for a
> > response to the ANN message.
> > Logging with -v all doesn't really show much. MythSocket
> > never logs anything for the port 6543/tcp after the
> > scheduler, although I do see MythSocket entries for the UPnP
> > SSDP packets being handled.
> > Anyone have any ideas? I am at a complete loss... logfiles
> > and a full strace available upon request!
> > Thanks!
> > --Matt
> > Oh, I should also mention that the connections to port 6543 are held
> > open indefinitely, if you use something like nc or telnet to open
> > the connection.
> Connections are handled by the socket server running in the main
> thread. Each request made on a socket is handled by one of a pool of
> threads. There is a known and as yet unresolved race condition that
> causes all of these threads to lock and not service any requests.
> That would result in the behavior here, where a connection can be
> made, but no responses ever come to any queries, with the frontend and
> bindings eventually timing out.
> What specific revision of MythTV are you running? There were a few
> fixes made several months ago, that based off the reduced frequence of
> this complaint on the mailing list, seems to have solved the issue for
> most users.
> mythtv-users mailing list
> mythtv-users at mythtv.org
I've seen this kind of behavior on my systems. I have a master BE with
only the database and a separate slave BE where all of the recording is
done. Most of the time it happens when the startup process is: start the
MBE, start the SBE and things just are not running correctly. Restarting
only the MBE clears the problem. It does not happen every time,
unfortunately. I am using master from earlier this week.
More information about the mythtv-users