Mailing List Archive: MythTV: Users

mythbackend not responding - and even more weirdness

Index | Next | Previous | View Threaded

waa-mythtv at revpol

Dec 16, 2006, 11:14 AM

Post #1 of 10 (3333 views)
Permalink

mythbackend not responding - and even more weirdness

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
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

fender_bender at aandr

Dec 16, 2006, 8:25 PM

Post #2 of 10 (3168 views)
Permalink

Re: mythbackend not responding - and even more weirdness [In reply to]

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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
> !DSPAM:458445e3106161162041270!

--
"Better to remain silent and be thought a fool than to speak out and remove
all doubt." - Abraham Lincoln
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

turbo at talstar

Dec 17, 2006, 6:48 AM

Post #3 of 10 (3170 views)
Permalink

Re: mythbackend not responding - and even more weirdness [In reply to]

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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

waa-mythtv at revpol

Dec 17, 2006, 7:30 AM

Post #4 of 10 (3154 views)
Permalink

Re: mythbackend not responding - and even more weirdness [In reply to]

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

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

waa-mythtv at revpol

Dec 17, 2006, 7:41 AM

Post #5 of 10 (3186 views)
Permalink

Re: mythbackend not responding - and even more weirdness [In reply to]

brian wrote:
> 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).

Well, I guess I misspoke initially. In my case recordings don't take
place when the backend is not responding, but I do see commflagging jobs
come and go - or at least the database queries and mythbackend logs show
them checking to start - but since no new recordings have taken place,
no commflagging jobs need to run. :)

> 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).

I had also seen that, but only ONE time. And since it was after a lot of
software updates on this box, I chalked that one up to the updates.
After the reboot, it has never done that since, so I am going to ignore
that in my case. :)

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

That is interesting, and something I am going to look into. The only
advice I got was from someone I can not remember telling me to "follow
instructions" and that "there are issues with mythtv .20 and MySQL 5" so
I dutifully exported my "mythconverg" and "mysql" databases, downgraded
MySQL to a 4.x version and imported the databases, and also had to
recompile PHP and qt against the downgraded MySQL.

Now I have been recently told that there really are no issues with
MythTV .20 and MySQL 5.x. :-/

In any case, the database just keeps chugging along through all of this.

Thanks for the suggestion, Brian.

> 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

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

waa-mythtv at revpol

Dec 18, 2006, 9:23 AM

Post #6 of 10 (3148 views)
Permalink

Re: mythbackend not responding - and even more weirdness [In reply to]

Brian said:
>>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.

Bill Arlofski said:
>That is interesting, and something I am going to look into.

OK, the results are in, but they are not good. I am still seeing the
same exact ssues. Everything works fine for a while, but then randomly
Mythbackend stops responding to the mythfrontend and the mythweb
interfaces until it is either restarted, or the strace is run agains the
mythbackend PID.

Running an strace with the -f parameter seems to wake it up and the
frontends work again and the scheduled recordings start again.

Would really love to know what may be causing this. :)

--
Bill Arlofski
Reverse Polarity

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

waa-mythtv at revpol

Dec 22, 2006, 9:27 AM

Post #7 of 10 (3126 views)
Permalink

Re: Update - FIXED mythbackend not responding - and even more weirdness [In reply to]

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

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

dusteur at excite

Dec 27, 2006, 6:40 AM

Post #8 of 10 (3078 views)
Permalink

Re: Update - FIXED mythbackend not responding - and even more weirdness [In reply to]

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

So, let's get this straight - you've "fixed" a mythtv threading issue by disabling one of the cores of your dual-core CPU?

I very strongly suspect you've simply made it less likely to occur...

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

waa-mythtv at revpol

Dec 27, 2006, 8:34 AM

Post #9 of 10 (3166 views)
Permalink

Re: Update - FIXED mythbackend not responding - and even more weirdness [In reply to]

Ryan Duffy wrote:
>
>
>
>> 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.
>>
>
> So, let's get this straight - you've "fixed" a mythtv threading issue by disabling one of the cores of your dual-core CPU?
>

Thanks for the comment Ryan.

The point of my follow-up post was not to say that I somehow magically
fixed mythtv or the actual problem, but rather that I found what appears
to be the cause and (for now) a temporary solution to the problem that
was plaguing me which no one could offer any insight into. As a matter
of fact, looking back, that is exactly what I said:

"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."

Perhaps a *PROBLEM ISOLATED, WORKAROUND FOUND* follow-up subject would
have been more clear. :)

I posted the follow-up comment with *FIXED*" in the subject in order to
hopefully generate some "hmmm, that's interesting, let's see what can be
done about really fixing the issue" type comments from any of the devs
that might be following the mythtv-users list. Also as a help to anyone
else that might be experiencing a similar issue on similar hardware.

Besides, I was excited to finally see mythtv running consistently on
this system and wanted anyone who may have been following the thread
that some progress had been made in my situation.

So having said all of that, were exactly is the problem? I don't know.

Is it strictly within the realm of the Linux kernel hackers'
responsibility to fix this? If yes, who's responsibility is it to report
it to them? Surely not an end user of a program. I'd hope a dev would
handle that type of escalation. :)

Does any of the burden of this problem fall on the mythtv devs? Is it a
programming issue with Mythtv and SMP? Is it an AMD Athlon64 X2 SMP
issue specific to the CPU I am using? Again, I do not know.

Not being a developer, I just try to report what I see in the hopes that
someone skilled in this area will pick up the ball and know exactly
what/where the problem lies, or will ask me for more information to get
to the bottom of it all.

> I very strongly suspect you've simply made it less likely to occur...

Well, 6 days, 17 hours and 59 minutes - still running, still responding.
I am pretty happy with that for now. :)

With an SMP-enabled kernel mythbackend failure is immanent - usually
within minutes or a few hours - It probably depends on if/when
recording/commflagging/transcoding is taking place. Never had the chance
to specifically narrow that down. Disabling SMP was the first course of
action.

Happy Holidays!

Thanks again to the MythTV devs.

--
Bill Arlofski
Reverse Polarity
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

markknecht at gmail

Dec 27, 2006, 8:48 AM

Post #10 of 10 (3083 views)
Permalink

Re: Update - FIXED mythbackend not responding - and even more weirdness [In reply to]

On 12/27/06, Bill Arlofski <waa-mythtv [at] revpol> wrote:
<SNIP>
>
> Does any of the burden of this problem fall on the mythtv devs? Is it a
> programming issue with Mythtv and SMP? Is it an AMD Athlon64 X2 SMP
> issue specific to the CPU I am using? Again, I do not know.
>
<SNIP>

Interesting results. It might well be SMP related. I have a P4HT
machine as the backend server and it's having similar problems.

We are having a lot of problems with mythbackend just shutting off,
but it seems to only shut off only when there are mythfrontend
machines that are just finishing watching programs. Over the Christmas
break we travelled for 4 days. mythbackend recorded everything
correctly for about 40 hours of material. Lots to watch, so we started
trying to do so. Yesterday mythbackend shut off 3 times. I'd restart
the backend and it would happen again maybe 1-2 hours later.

Thanks for the SMP idea. I'll look at that and report back.

Cheers,
Mark
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads