<br><br><div class="gmail_quote">On 19 February 2010 18:55, Paul Harrison <span dir="ltr"><<a href="mailto:mythtv@sky.com">mythtv@sky.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[snip]<br>
<br>
OK, thanks for taking the time to produce the log. It does look like a<br>
problem with the new MythSignalingTimer leaking memory when the main<br>
thread in mythwelcome isn't running. I think it's because the<br>
MythSignalingTimer is run in it's own thread and so continues to emit<br>
signals even when the main thread isn't running and so the signals just<br>
get queued up waiting for the main thread to resume.<br>
<br></blockquote><div>That's no problem, thanks for debugging it for me. <br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So the fix looks like it would be to stop the MythSignalingTimer in<br>
MythMainWindow when mythsystem() is used to start an external process<br>
and resume it again when it finishes. I'll have a look at trying this<br>
over the weekend.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div>FWIW, I popped a changeEvent handler on MythMainWindow and did 'd->drawTimer->stop()' on activation loss, which seems to have cured the problem for mythwelcome (although not for mythfrontend launching xbmc, but I suspect that's due to the dirtyness of my patch.) This does however solve the main problem of not being able to do anything with the remote that I was having. (ssh to reboot all the time is tedious.) so I'm happy. <br>
<br>Thanks again for the clear and concise fix. :)<br><br>Cheers,<br><br>Ian<br><br></div></div>