paradise lost... 1.5.31 problems came back

[johnsonx42]

In the 1.5.33 announcement thread I posted this bit of exuberance:

Also, I find 1.5.33 to be a MAJOR improvement over 1.5.31. 1.5.33 resolved several issues on my HTPC that I had assumed were non-NPVR related. First, and perhaps weirdest, I was getting a serious clock drift as much as 4 minutes ahead per day - it never occurred to me to pin this on NPVR, but after installing 1.5.33 and changing nothing else the clock now keeps perfect time again. Also, when skipping ahead or back in a recording, playback would often freeze for many seconds or even forever; I figured that was decoders or video driver, yet again installing 1.5.33 has completely eliminated that problem.

Finally, I (among others) had noted a rather high CPU utilization by NRecord.exe even when it was doing nothing at all, causing my fans to spin up a lot and other issues as well; now with 1.5.33 NRecord.exe idles at 0%.

It does occur to me that all 3 issues could have been related somehow. Either way, hooray for 1.5.33!

All 3 issues are now back. I think the clock drift has to be for some other reason; the CMOS battery is probably just dead. It was likely just coincidence that it went through a period of stability at the same time I put in 1.5.33, and at any rate the return of the clock drift preceeded the return of the other two symptoms by several days.

The next two issues I think are actually related somehow. Both came back after I restarted the recording service due to this issue: http://forums.gbpvr.com//showthread.php?...post392564. I've restarted it again since then, and the whole system as well, with no improvement. Absolutely nothing has changed on the system - all I did was restart the recording service after it hung.

Playback often freezes after skipping (whether manually using the skip buttons or for an auto-comskip); to get playback going again I have to skip back and forth a couple of times and with some patience I can get it to go again. When I first installed 1.5.33 skipping was quick and effortless, now it's slow and painful.

The skipping problems occur on any recording, regardless of when it was made, so it's clearly a playback problem and not a recording problem.

NRecord.exe is now back to idling at 20% CPU. And as I mentioned in the thread discussing this awhile back, that's 20% on a dual-core system, meaning it's 40% of a single core - very high for doing nothing.

[johnsonx42]

Confirmed, the NRecord high-cpu utilization and the skipping problems are definitely related. I shut down NRecord.exe and ran NextPVR.exe by itself. Skipping is now buttery-smooth.

[whurlston]

Regarding the clock drift: I think it was just coincidence that it was fixed at the same time you installed 1.5.33. Try changing your Internet time server to time.nist.gov. I always have trouble syncing to the default (time.windows.com).

[johnsonx42]

I'm syncing time to us.pool.ntp.org every 12 hours. The clock actually drifts as much as 3 minutes in just 12 hours some days, and it always drifts ahead, never behind (which is also a little weird - clock drift is almost always the other way). I do agree that it probably was just coincidence. However now that I've shut down NRecord it will be interesting to see if the clock drift goes away again. The system works so much better without NRecord running, it's a night and day difference; but of course now I have to be careful not to accidentally shutdown NextPVR at the wrong time, as now the recording process goes with it.

What I find odd about all of this is if there's some sort of problem causing NRecord to run with high CPU utilization and cause all these problems, why doesn't the recording service launched by NextPVR.exe do the same thing? As far as I understand NRecord and NextPVR both launch the same recording service process from the same .dll's.

Also, the problem is more than simple CPU utilization - when I posted above that the skipping was smooth again after shutting down NRecord, there was a comskip process running using 40% CPU and obviously doing a lot of I/O, but that had no effect on playback and skipping performance; yet whatever NRecord was doing causing only 20% CPU usage killed the skipping.

[sub]

NRecord is definitely not causing your clock drift. Its definitely not using any of the Windows calls to set the time.

[johnsonx42]

Any comments though on the bigger issue of high cpu utilization by NRecord and the skipping problems caused by that?

[whurlston]

Are you running any postprocessing or parallelprocessing scripts? They could be causing the high CPU usage.

[johnsonx42]

Yes, but the high cpu usage by NRecord.exe happens while it's doing nothing at all; even after a reboot or service restart, it starts idling at 20% and stays that way forever. Recording doesn't even significantly increase the usage, maybe 1 or 2%. I'm not the only one with this problem by the way, there was a thread about this a month ago where quite a few users chimed in with high utilization by NRecord, but at the time no one understood the problem to be anything more serious than that. I'd be willing to bet too that the numerous people who have complained about skipping problems in 1.5.33 also have the high cpu-utlization problem as well.

An interesting aside: since shutting down NRecord last night, the clock has not gained or lost so much as a second. It's not proof yet, and I still don't understand how NRecord could cause clock drift, but there it is.

[sub]

Any comments though on the bigger issue of high cpu utilization by NRecord and the skipping problems caused by that?

I dont know. I've not seen this high CPU myself. I can look into it when I'm back though.

[johnsonx42]

Thanks, I'll stop pestering for awhile. For now everything is working great running without NRecord.

edit: ARGH! without NRecord there's no NEWA, and without NEWA there's no SearchLite! :mad: I'll live, but not for long!

another edit: is it possible then that NEWA is causing the high cpu utilization? NEWA is the primary difference between the recording service launched by NRecord vs. the one from NextPVR, right? can I tell NRecord to run without NEWA?