<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 11/18/2011 16:07, Matt Mossholder wrote:
<blockquote
cite="mid:CAA_WKe9wg6smewogUCxkAfn3aJvEsEnOy_CrHDW8hiKckEfDUA@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Fri, Nov 18, 2011 at 3:37 PM, Matt
Mossholder <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:matt@mossholder.com">matt@mossholder.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.
<div><br>
</div>
<div>
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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Anyone have any ideas? I am at a complete loss...
logfiles and a full strace available upon request!</div>
<div><br>
</div>
<div>
<div>Thanks!</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div> --Matt<br>
</div>
</font></span></div>
</blockquote>
</div>
<br>
<div><br>
</div>
<div>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. <br>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
</body>
</html>