[mythtv] Ticket #10414: HDHomeRun: Bad Recordings

Tom Lichti tom at redpepperracing.com
Mon Mar 12 00:57:58 UTC 2012


On Sun, Mar 11, 2012 at 4:29 PM, David Engel <david at istwok.net> wrote:
> On Sun, Mar 11, 2012 at 02:40:19PM -0400, Bruce Taber wrote:
>> On 03/11/2012 12:25 PM, David Engel wrote:
>> > On Sun, Mar 11, 2012 at 12:13:21PM -0400, Daniel Kristjansson wrote:
>> >> On Sun, 2012-03-11 at 10:50 -0400, Tom Lichti wrote:
>> >>> On Sat, Mar 10, 2012 at 8:41 PM, Gary Buhrmaster
>> >>> <gary.buhrmaster at gmail.com>  wrote:
>> >>> Then may I respectfully suggest that we are going down the wrong path
>> >>> on this? I've used the default network settings, the tweaked settings
>> >>> on the page Daniel suggested, and Daniel's own settings, and none of
>> >>> them has made a difference. The only thing that made any noticeable
>> >>> difference was Daniel's commit the other day, but that only made
>> >>> recordings go from completely un-watchable to highly annoying (and
>> >>> still un-watchable).
>> >> Thanks for testing the network settings though it was important
>> >> to eliminate that possibility. I've also gotten a report off-line
>> >> that logging is not the culprit. So far the only commonality
>> >> appears to be high CPU usage. My commit slightly lowered CPU usage,
>> >> but increasing that timeout further won't do much.
>> >>
>> >> I plan to run an oprofile on mythbackend with a couple HDHomeRun
>> >> recordings going sometime in the coming week. Even though I'm not
>> >> seeing the issue on my i5, it should still show where CPU is being
>> >> used and hopefully show something useful.
>> > I'm running a git bisect today to try to find when the higher CPU
>> > usage started.  That might not be the real cause of the problem, but I
>> > still want to figure that out.
>> >
>> > David
>> I began to see these types of bad recordings about the same time as the
>> commit for the code that flags them as bad. Back in November? I don't
>> believe that was the culprit but more of a coincidence. I don't really
>> have a way to determine that beyond a shadow of a doubt.
>
> Your recollection is spot on except for being just a hair off on the
> timing.
>
> Daniel, I traced my high CPU usage to the following commit.
>
> commit ca0419d8969b97bba80c590e5fed02f7c1d948c8
> Author: Daniel Thor Kristjansson <danielk at cuymedia.net>
> Date:   Fri Dec 2 16:19:42 2011 -0500
>
>    Adds recording quality tracking to DTV recorders.
>
> Specifically, it is the following code in DTVRecorder::BufferedWrite().
>
>    if (!timeOfFirstData.isValid() && curRecording)
>    {
>        QMutexLocker locker(&statisticsLock);
>        timeOfFirstData = mythCurrentDateTime();
>    }
>
>    uint64_t now = mythCurrentDateTime().toTime_t();
>    if (!timeOfLatestData.isValid() || (now - timeOfLatestData.toTime_t() >= 5))
>    {
>        QMutexLocker locker(&statisticsLock);
>        timeOfLatestData = mythCurrentDateTime();
>    }
>
> With that code commented out and 6 tuners busy, my mythbackend CPU
> usage drops from ~150% (1.5 of 2 cores busy) to ~20%.  The
> QMutexLocker is responsible for some of the higher usage, but the
> biggest culprits are the toTime_t() and isValid() time calls.

Is it just a matter of commenting out those lines? If so, I can try
that tonight.

Tom


More information about the mythtv-dev mailing list