danielk at cuymedia
Jun 24, 2012, 5:00 PM
Post #5 of 5
(304 views)
Permalink
|
|
Re: [mythtv-commits] Ticket #10853: Clock Doesn't Update
[In reply to]
|
|
On 06/24/2012 07:10 PM, Stuart Morgan wrote:
> On Monday 25 Jun 2012 08:49:32 Jean-Yves Avenard wrote:
>> On Monday, 25 June 2012, Jim Stichnoth wrote:
>>> This looks more like something missed in the UTC conversion.
>>
>> Unlikely.
>> He did mention using 0.25-fixes..
>
> No, it was the UTC conversion and Jim has already pushed a fix.
>
> George was reporting a hung process when using 0.25-fixes which also meant the
> clock wasn't updated, but which wasn't the issue reported in #10853
It was my fault, but not from the big UTC merge. It was caused by
[14ad67e0], which I committed on Friday. I had left the clock in
local time when I did the initial UTC conversion. But when I was
looking for the cause of the high CPU usage I noticed that that
keeping that in local time was causing some of the CPU usage in
the frontend. QDateTime::currentDateTime() always does a timezone
conversion and we were doing this 70 times a second. Using
MythDate::current() avoids the timezone conversion as of [19d60955]
as long as you have Qt 4.7 or later.
Jim found the real cause of the CPU use in the frontend as well.
It was due to expiring an image cache. I had made an error when
fixing a memory leak that caused one of the images caches to be
effectively disabled.
We still haven't found the source of the high memory use in all
the myth applications and large CPU usage on the backend. It
appears to have started with the zeromq merge, but even that
isn't 100% verified yet.
-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev
|
