[mythtv-users] mythbackend not responding - and even more weirdness

brian turbo at talstar.com
Sun Dec 17 14:48:09 UTC 2006


Bill --

   I saw a similar situation here (running current SVN) a week or so
ago.  mythweb, mythfrontend, and mythwelcome couldn't connect to the
backend and all complained it may not be running.  Meanwhile, any
scheduled recordings (and associated jobs such as commercial flagging)
continued on as usual (more or less).  

   When I ran `top` via ssh on the myth server, I found that the
mythbackend process was consuming 98+ % of the CPU, even when it should
be "doing nothing".  I would shutdown/restart the machine and all would
be well, for a while (maybe a day or so).

   One of the guys in the #mythtv-users channel (GreyFoxx) suggested it
may be related to a upnp issue, and that I try invoking mythbackend with
the '--noupnp' parameter.  In my situation, this seems to have cleared
up the issue -- I've not had that problem recur over the past week or
so.

On Sat, 2006-12-16 at 14:14 -0500, Bill Arlofski wrote:
> 
> Hello everyone. I just joined the list and I apologize for such a long
> first post, but I am seeing such a strange set of issues so I will try
> to include as much info right up front. Please bear with me. :)
> 
> 
> Lemme try to explain:
> 
> Everything works fine for a while, then randomly the mythbackend stops
> responding to the frontend (and the Mythweb interface). But, mythbackend
> is not 'hung'. It continues to query the MySQL database, and continues
> to log to its own mythbackend.log. (nothing interesting jumps out at me
> in that log though)
> 
> The frontend will timeout and complain that the backend is gone, and of
> course the "Watch Recordings" page and "Scheduled recordings" pages are
> blank.
> 
> But... here is the strange part: If I run strace without the -f (follow
> child processes) I get this:
> 
> # strace -s0 -p 26534
> Process 26534 attached - interrupt to quit
> futex(0x654618, FUTEX_WAIT, 2, NULL
> 
> And it just sits there... and nothing changes in the frontend (which is
> running in a window for easy monitoring).
> 
> BUT if I run that same strace with the -f parameter, all of a sudden the
> mythfrontend comes alive and is able to communicate with the backend and
> the "Watch recordings" page is automatically populated and I can choose
> a recording to watch and it works fine.
> 
> When the strace -f process is killed, the mythfrontend again can no
> longer communicate with the backend... Restart the strace -f and the
> mythfrontend comes back to life and works perfectly again.
> 
> Meanwhile, whenever the backend is not responding to the frontend, no
> scheduled recordings take place, and the mythfrontend logs:
> 
> 2006-12-16 13:48:24.328 Connecting to backend server: 192.168.254.4:6543
> (try 1 of 5)
> 2006-12-16 13:48:31.332 MythSocket(2aaab1cf1f50:34): readStringList:
> Error, timeout (quick).
> 2006-12-16 13:48:31.332 Unexpected response to MYTH_PROTO_VERSION:
> 2006-12-16 13:48:31.332 ProgramList::FromScheduler(): Error querying master.
> 
> 
> I know. This is very strange. I was just running strace to see what
> mythbackend was trying to do when it was not responding to the frontend.
> No idea why or how strace could affect how the backend process acts.
> 
> Here are the system details:
> 
> - Gentoo Linux
> - AMD Athlon64 X2
> - 2GB RAM
> - # free
>              total       used       free
> Mem:       2059492    2035936      23556
> -/+ buffers/cache:    1384692     674800
> Swap:      1028000     436108     591892
> 
> - Hauppauge Wintv-PVR500 dual tuner card
> - ivtv version 0.8.1 (tagged release) loading
> - Kernel Linux version: 2.6.18 SMP preempt mod_unload gcc-3.4
> (I just noticed the preempt above. I thought I read somewhere NOT to use
> that kernel option with MythTV... Could that be it?)
> 
> - /mnt/store is an NFS mount with the following mount options:
> remote_server:/mnt/store on /mnt/store type nfs
> (rw,rsize=8192,wsize=8192,hard,intr,nfsvers=3,actimeo=0,addr=192.168.254.3)
> 
> - Filesystem on remote server is jfs
> - MySQL database is v4.1.22
> - mythbackend --version reports:
> Library API version: 0.20.20060828-3
> Source code version: exported
> Options compiled in:
>  linux release using_lmsensors using_v4l using_oss using_alsa using_ivtv
> using_firewire using_x11 using_xv using_xrandr using_opengl_vsync
> using_opengl using_frontend using_backend using_bindings_perl
> 
> - $ mythfrontend --version reports:
> 2006-12-16 13:40:20.588 Using runtime prefix = /usr
> 2006-12-16 13:40:20.597 DPMS is disabled.
> 2006-12-16 13:40:20.629 New DB connection, total: 1
> 2006-12-16 13:40:20.637 Connected to database 'mythconverg' at host:
> localhost
> 2006-12-16 13:40:20.639 Total desktop dim: 1680x1050, with 1 screen[s].
> 2006-12-16 13:40:20.644 Using screen 0, 1680x1050 at 0,0
> Library API version: 0.20.20060828-3
> Source code version: exported
> Options compiled in:
>  linux release using_lmsensors using_v4l using_oss using_alsa using_ivtv
> using_firewire using_x11 using_xv using_xrandr using_opengl_vsync
> using_opengl using_frontend using_backend using_bindings_perl
> 
> Neither processor ever has more than a 20% utilization - both fluctuate
> anywhere between 0 and 20 and this is with other apps opened and
> running. Also system load sits around 0.6 so there are no system loading
> issues. :-/
> 
> 
> ANY and ALL thoughts are appreciated. I would be willing to provide any
> additional information to help resolve this issue.
> 
> BTW, from what I have seen so far MythTV is pretty awesome. Nice job
> devs!  :)
> 
> --
> Bill Arlofski
> Reverse Polarity
> waa-mythtv at revpol.com
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> 



More information about the mythtv-users mailing list