[mythtv] [mythtv-commits] Ticket #1805: Backend not responding, with backtrace and log
Jim Westfall
jwestfall at surrealistic.net
Wed May 24 00:39:04 UTC 2006
MythTV <mythtv at cvs.mythtv.org> wrote [05.22.06]:
> #1805: Backend not responding, with backtrace and log
> -------------------------------------+--------------------------------------
> Reporter: tom at redpepperracing.com | Owner: ijr
> Type: defect | Status: new
> Priority: minor | Milestone:
> Component: mythtv | Version:
> Severity: medium | Resolution:
> -------------------------------------+--------------------------------------
> Comment (by tom at redpepperracing.com):
>
> Just happened again, I believe the comment on the -dev list about it
> having to do with a slave backend generating a thumbnail is correct. This
> time when it happened I had all tuner in the master being used, and the
> first tuner in the slave jsut started a recording, and when I went to the
> frontend to look at the recordings list, the front end hung; the slave
> recording was the first in the list, and there was no thumbnail. I managed
> to get a backtrace from the master, the slave gave me an error when I
> tried to generate the bt, and I have logs from both backends. See
> attached.
>
It would be most helpful to get a backtrace on that slave backend so see
what its doing.
The master backend is stuck in the following loop with a lock on the
slave backend socket.
while (socket->waitForMore(5) < 8)
{
if (socket->state() != QSocket::Connected)
{
// dunno if socket->state() wants the app lock. be safe for now.
qApp->unlock();
return false;
}
qApp->unlock();
usleep(500);
qApp->lock();
}
The question is, is the slave backend not responding to the genpixmap
request for some unknown reason or has the socket gone away and
socket->waitForMore() isnt enough to trigger a state change on to
!QSocket::Connected.
jim
More information about the mythtv-dev
mailing list