id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,mlocked 9123,frontend and backend get stuck after live tv channel change using HD-PVR,Johnny Stenback ,cpinkham,"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) () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0x00007f00dd1d774c in QFile::open(QFlags) () 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) () 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) () 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.",defect,closed,minor,0.24,MythTV - General,Master Head,medium,Fixed,,,0