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

[Bill Arlofski]

Thanks to |Torg|, kormoc and others in the #mythtv-users IRC channel it
seems we found a possible cause and at least a quick fix.

I am no kernel hacker, but |Torg| pointed me to this:
http://lkml.org/lkml/2006/4/12/64 , along with the thought that there is
or may be timing issue between the two cores which was causing
Mythbackend to stop responding.

Disabling SMP support in my 2.6.18 "vanilla" kernel (gentoo-speak) on
this AMD Athlon64 X2 dual core system seems to have cleared up the
problem I originally described where the Mythbackend randomly stopped
responding to the frontend(s).

It has been running for almost 48 hours now, recording, commflagging,
transcoding and talking to multiple frontends, including mythweb - so
far no issues to report since SMP was disabled.





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
> _______________________________________________