david at istwok
Mar 11, 2012, 6:07 PM
Post #18 of 21
(650 views)
Permalink
|
|
Re: Ticket #10414: HDHomeRun: Bad Recordings
[In reply to]
|
|
On Sun, Mar 11, 2012 at 08:57:58PM -0400, Tom Lichti wrote:
> On Sun, Mar 11, 2012 at 4:29 PM, David Engel <david [at] istwok> 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> 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>
> > 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.
Doing so could very likely cause the damaged recording detection to
mark everything as damaged. If you don't mind that or can have a time
window just for testing, then sure, give it a try.
David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev
|
