[mythtv-users] everyday i have to make sure myth worked the day before

Tom Lichti redpepperracing at gmail.com
Wed Apr 20 13:47:53 UTC 2011


On Wed, Apr 20, 2011 at 12:24 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 04/19/2011 11:37 PM, Brian J. Murrell wrote:
>> Yeah, most definitely back with a vengeance.  Again tonight:
> ...
>> 2011-04-19 22:04:30.209 MythCoreContext: Connecting to backend server:
>> 10.75.22.2:6543 (try 1 of 5)
>> 2011-04-19 22:04:30.261 MythCoreContext: Connecting to backend server:
>> 10.75.22.2:6543 (try 1 of 5)
>> 2011-04-19 22:04:37.214 MythSocket(892d960:11): readStringList: Error,
>> timed out after 7000 ms.
>> 2011-04-19 22:04:37.215 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.
> ...

> When the socket issues first started happening--they seemed to come out
> of nowhere as people started upgrading their systems to newer libraries
> or kernels or something--they were very common on most systems.  Then
> Daniel K rewrote the socket code, and this solved the issue for the
> majority of users.  Unfortunately, the issue still occurs for some
> users.  Because the issue is very system/timing/... dependent, we
> haven't found a way for someone who hasn't been seeing the issues to
> reproduce them.  Therefore, it is going to be /very/ difficult for
> anyone to fix until someone who actually sees the problem can diagnose
> (and/or fix) it.
>
> That said, it's possible that "changing up your system" may allow you to
> run mythbackend without the issue.  (Unfortunately, I don't know what
> all you might need to change up--processor,  distro version, distro, RAM
> (speed or capacity), NIC, ...)

I don't think it is the system, at least not in my case. I had been running:

mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.25pre-1579-g786a95f
MythTV Branch    : master
Network Protocol : 65
Library API      : 0.25.20110328-2
QT Version       : 4.6.3
Options compiled in:
 linux debug use_hidesyms using_alsa using_oss using_backend
using_bindings_perl using_bindings_python using_bindings_php using_dvb
using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv
using_joystick_menu using_lirc using_mheg using_opengl_video
using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr
using_bindings_perl using_bindings_python using_bindings_php
using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads
using_live using_mheg

until yesterday and I have never seen this socket problem. Yesterday I
updated to current trunk:

mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.25pre-1799-gb1a731e
MythTV Branch    : master
Network Protocol : 65
Library API      : 0.25.20110414-3
QT Version       : 4.6.3
Options compiled in:
 linux debug use_hidesyms using_alsa using_oss using_backend
using_bindings_perl using_bindings_python using_bindings_php using_dvb
using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv
using_joystick_menu using_lirc using_mheg using_opengl_video
using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr
using_bindings_perl using_bindings_python using_bindings_php
using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads
using_live using_mheg

and I can reproduce this error at will, anytime. All I have to do is
run the backend with default logging and then try and do anything from
a frontend or mythweb, and it will deadlock instantly. I am currently
running with -v socket and it is somewhat stable, enough that I can at
least record and watch stuff (with only one frontend at a time though)
but commflagging is segfaulting everytime.

The ONLY thing that changed as well yesterday on my backend is:

Apr 19 10:28:15 Updated: 1:cups-libs-1.4.6-1.fc13.i686
Apr 19 10:28:16 Updated: file-libs-5.04-7.fc13.i686
Apr 19 10:28:17 Updated: file-5.04-7.fc13.i686
Apr 19 10:28:29 Updated: 1:cups-1.4.6-1.fc13.i686
Apr 19 10:28:30 Updated: 12:dhclient-4.1.2-4.ESV.R2.fc13.i686
Apr 19 10:28:32 Updated: 3:perl-version-0.82-2.fc13.i686

I can't see any of those things making mythtv sockets all of a sudden
crap out. As you can see, I am running a debug build, so if there are
suggestions as to what I can do to help get this fixed, please let me
know, but it seems to me it has to be the mythtv code, because my
system was running absolutely rock solid with v0.25pre-1579-g786a95f,
and with  v0.25pre-1799-gb1a731e it's almost unusable.

Tom


More information about the mythtv-users mailing list