[mythtv-users] Really strange one...

[Bruce Taber]

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
> http://www.mythtv.org/mailman/listinfo/mythtv-users
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.

Bruce