[mythtv-commits] Ticket #9123: frontend and backend get stuck after live tv channel change using HD-PVR
MythTV
mythtv at cvs.mythtv.org
Wed Oct 20 07:17:49 UTC 2010
#9123: frontend and backend get stuck after live tv channel change using HD-PVR
----------------------------------------------------------+-----------------
Reporter: Johnny Stenback <mythtv-users@…> | Type: defect
Status: new | Priority: major
Milestone: 0.24 | Component: MythTV - General
Version: Unspecified | Severity: medium
Keywords: | Ticket locked: 0
----------------------------------------------------------+-----------------
This is somewhat of a complex problem in that the only way I'm able to
attempt to reproduce this is in my full production system which consists
of a master backend, a separate combined frontend/slave backend, and a
separate frontend. My system setup is as follows:
Master backend: mythbackend running, no frontend. One PVR-250 installed in
the box. This is my secondary encoder. Big beefy server (well, sort of)
Combined frontend/slave: mythfrontend running, and mythbackend running as
a slave, with a HD-PVR attached and configured. This is my primary
encoder. Zotac ION based system, low powered atom, using VDPAU for
playback.
Frontend only: Identical hardware to the combined frontend, but no slave
running here.
This system has worked very well on 0.23 since it was released, and on
trunk builds from before then, for over a year now. Yesterday I took the
plunge to update to trunk builds as trunk was getting close to 0.24, and
in fact the branch had just gotten created when I pulled, but I ended up
at rev 26886. Anyways, the system seems to work very well for recording
and watching recordings, and for live tv as well as long as I either watch
live tv from the PVR-250. But if I watch live tv from the HD-PVR, attached
to the slave backend, then it stops working at the first channel change.
What happens is this. I start live tv on the combined frontend/slave and
either end up on the HD-PVR input or change to it, I see the signal
monitor doing it's thing, I typically see the dialog saying "You should
have received a signal by now..." (I have a 3 second sleep in my channel
changing script), and eventually the channel change is done and
everything's good. Video is playing, audio is fine, nothing wrong. Then
when I change channels, I get the signal monitor again, and after a couple
of seconds I get the dialog saying "You should have received a signal by
now..." behind the signal monitor. At this point the frontend appears to
lock up. No way out. But it's not deadlocked, it uses ~100% CPU at this
point (~10% before this point), and the slave backend *also* is pegged
using ~100% CPU. No buttons on the remote get me out of this (short of the
one I have set to kill the frontend to restart it if it gets locked up).
If I attach to the frontend process with gdb at the point when the
frontend locks up and interrupt a bunch of times, I see stack traces that
mostly look like this:
#0 0x00007f00dcebaaed in open64 () from /lib/libpthread.so.0
#1 0x00007f00dd21e42a in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#2 0x00007f00dd216879 in
QFSFileEngine::open(QFlags<QIODevice::OpenModeFlag>)
() from /usr/lib/qt4/lib/libQtCore.so.4
#3 0x00007f00dd1d774c in QFile::open(QFlags<QIODevice::OpenModeFlag>) ()
from /usr/lib/qt4/lib/libQtCore.so.4
#4 0x00007f00dd745ca0 in ?? () from /usr/lib/qt4/lib/libQtGui.so.4
#5 0x00007f00dd746b0b in QImageReader::supportsAnimation() const ()
from /usr/lib/qt4/lib/libQtGui.so.4
#6 0x00007f00de459d8f in MythUIImage::Load(bool, bool) ()
from /usr/lib/libmythui-0.24.so.0
#7 0x00007f00dea3664d in ?? () from /usr/lib/libmythtv-0.24.so.0
#8 0x00007f00de940b1a in TV::UpdateOSDSignal(PlayerContext const*,
QStringList const&) () from /usr/lib/libmythtv-0.24.so.0
#9 0x00007f00de96f94b in TV::customEvent(QEvent*) ()
from /usr/lib/libmythtv-0.24.so.0
#10 0x00007f00dd25d29c in QObject::event(QEvent*) ()
from /usr/lib/qt4/lib/libQtCore.so.4
#11 0x00007f00de90efbd in TV::event(QEvent*) ()
from /usr/lib/libmythtv-0.24.so.0
#12 0x00007f00dd67ca04 in QApplicationPrivate::notify_helper(QObject*,
QEvent*)
() from /usr/lib/qt4/lib/libQtGui.so.4
#13 0x00007f00dd682e2f in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/qt4/lib/libQtGui.so.4
#14 0x00007f00dd246fcc in QCoreApplication::notifyInternal(QObject*,
QEvent*)
() from /usr/lib/qt4/lib/libQtCore.so.4
#15 0x00007f00dd249ef4 in
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
from /usr/lib/qt4/lib/libQtCore.so.4
#16 0x00007f00dd2740d3 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4
#17 0x00007f00d9626188 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#18 0x00007f00d9626768 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0x00007f00d9626a0a in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#20 0x00007f00dd2744ff in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
() from /usr/lib/qt4/lib/libQtCore.so.4
#21 0x00007f00dd71ea4e in ?? () from /usr/lib/qt4/lib/libQtGui.so.4
#22 0x00007f00dd24a2bf in
QCoreApplication::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/qt4/lib/libQtCore.so.4
or variations thereof, but the common thing is that the frontend is pretty
much always in something that's called from TV::UpdateOSDSignal(). And
we're not locked up in anything there, we keep getting new messages that
land us in the same place over and over. Attaching to the backend with gdb
shows that it's doing various things, processing events, writing to a
socket (MythSocket::writeStringList()), but nothing consistent or
obviously interesting that I've seen yet. But I only did get a couple of
stacks from the backend.
All the while, the master backend seems mostly unaffected by any of this,
at least to the point where a simultaneous live tv instance watching off
of the PVR-250 keeps running in another frontend running in a small window
on a separate unrelated linux box (for testing only). Though it does seem
like things are a bit sluggish, so the master may be involved one way or
another.
I'll attach logs as well (from a different instance than when I grabbed
the stacks, but the behavior was identical). And filing this against 0.24,
even if this was seen with the rev just past the branch point. Feel free
to adjust milestone and priorities etc as I'm mostly guessing on those.
--
Ticket URL: <http://svn.mythtv.org/trac/ticket/9123>
MythTV <http://www.mythtv.org/>
MythTV Media Center
More information about the mythtv-commits
mailing list