<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
On 10-10-20 08:00 AM, <a class="moz-txt-link-abbreviated" href="mailto:mythtv-commits-request@mythtv.org">mythtv-commits-request@mythtv.org</a> wrote: <br>
<blockquote
cite="mid:mailman.1.1287576001.13949.mythtv-commits@mythtv.org"
type="cite">
<pre> 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 <b class="moz-txt-star"><span class="moz-txt-tag">*</span>also<span class="moz-txt-tag">*</span></b> 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).
</pre>
</blockquote>
For what it's worth, I've noticed similar behaviour changing
channels in 0.24 using an HD-PVR and an external firewire channel
changing script - the signal monitor pops up (within 2 seconds)
long before the channel change script is finished (I have a five
second delay in my script.) Changes in 0.23 were fine with the
signalmonitor patch compiled in.<br>
<br>
Occasionally changing channels I get the message "Error opening jump
program file buffer" and I wind up back at the main menu again -
last time I ran into this the front-end segfaulted when I tried to
re-start live tv.<br>
<br>
This was on a combined FE/BE, but I didn't have any CPU utilisation
issues.<br>
</body>
</html>