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

Bill Arlofski waa-mythtv at revpol.com
Sun Dec 17 15:30:40 UTC 2006


Hi Darren. All of what I descibed is on one machine. The backend is
bound to the LAN IP 192.168.254.4, not the loopback IP of 127.0.0.1 so
that it will be accessible to other machines on the LAN when everything
is functioning properly.

I was seeing the same issues when the backend was bound to the loopback
address.



Darren wrote:
> Most likely network or somehow the ports a getting blocked. You can check for 
> open or listening ports using netstat -lp |grep myth as root, route -n will 
> show the routing table more important is the gateway if there is one. If 
> network settings are ok then check the system logs 
> 
> goodluck
> Darren
> 
>> 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



More information about the mythtv-users mailing list