CPU activity associated with WinTV PVR recording

[salsbst]

Disclaimer: I'm not sure that this has anything to do with the beta, because for quite a while I never monitored this issue when using v5.

I'm seeing 15-30% CPU usage for SageTV (it's a P4, 1.8GHz, IIRC) on my machine while it is recording using the WinTV PVR 500. Is that normal?

I see virtually no CPU usage associated with network recording that takes place on another machine (as I would expect). But for local recording, 15-30% of a P4 seems awfully high to me, when the card is supposed to be able to record directly to the drive. There is nothing in the Sage log file to indicate something exciting is being done using the CPU.

Is this normal?

What horsepower does everyone else see being absorbed by WinTV PVR 500 recording?

TIA,
Stuart

[ToxMox]

Not normal at all. I have two PVR 500s and when recording with all 4 tuners the Sage service uses 5% or less cpu.
Are you using drive letters or UNC paths for your recording dirs?

CPU is Athlon 64 3500+

[ToxMox]

Also wondering what else is running on that machine. Any antivirus or similar app perhaps?

[salsbst]

UNC paths to local drives. I've excluded those drives from Norton AV scanning. Just checking: if it were AV-related, the CPU activity should show up under the AV's exe, right?

[ToxMox]

Well if the virus scanning was constantly pinging the files as they are being recorded I could see it slow down the executable that is trying to write the file.
I'm curious about UNC though. I use local drive letters...no UNC. I messed around with UNC a few months ago just to test something and I experienced some strange issues so I immediately went back to drive letters.

[salsbst]

Even slowing down the process that is trying to write the files shouldn't result in significant extra CPU usage by that slowed-down process, should it? At least, I wouldn't think so.

Concerning UNC, at least Windows knows not to go through the network card to access the local drive, but I suppose it is possible that it doesn't know enough to avoid the network stack as a whole.

Ah, but something just occurred to me. I have two network encoders, SGraphRecorder and HDHomeRun on a different server. Those encoders are also writing to a UNC path (which is also local to the machine one which the encoders run), and they are writing much bigger bandwidth, and that machine is also running Norton Antivirus (and the drive in question is excluded from NAV). Guess what? Almost 0% CPU usage combined between those encoders.

Is it possible that PCI cards aren't as good at writing to UNC paths that represent drives on the local machine? (Grasping at straws, here.)

[ToxMox]

I guess we can't rule out UNC for sure until you do a test of using drive letters vs UNC.
If that doesn't work I would start killing processes running on the server one by one and see if it is some sort of conflict with a specific program.

[nielm]

I got <2% (ath64 3000+) used by the service when simultaneously recording with a PVR-250 and a PVR-150MCE.

I think disk IO and network IO will show up under the 'System' process if for some reason they use a lot of CPU. I also think that if a process is blocked due to IO, it will use 0 CPU.

This is 15-20% used by the sageTV *process* (not the system wide cpu usage?), and you are not using service mode?

Are you using the base STV with no hidden extras and no 'load_on_startup_runnable_classes' (just in case it's a plugin problem)

One thing that for me caused the service/server CPU to go up to rediculous levels was a rogue SageTVTranscoder process (it itself was using 0%cpu, but the service was using 40% of an Ath64 3000+), so you may want to check for them and kill them.

[salsbst]

Yes, this is CPU% used by the Sage process itself.

Most recently, I've observed it when running sagetvservice.exe on its own (no GUI), but I'm fairly sure that I saw the same when running as sagetv.exe (with no backing service). I'll double-check that, though.

I had a lot of rogue transcoding going on this weekend, but after a clean install, that seems to be under control.

This CPU activity is observable with the base STV and no runnable modules or anything of the sort, and is seems to be correlated with recording on the WinTV PVR/local disk via UNC. The process is nice and quiet (0-1%) when WinTV recordings are not in-progress. As I mentioned above, my two other encoders don't chew on the CPU when recording to a UNC drive, so I'm somewhat confident that UNC is not fundamentally at fault, though it could certainly be interaction bewteen Sage and UNC.

EDIT: I left out the bolded not above, which was not at all what I meant.

[nielm]

Forgot to mention above that I am also using UNC paths to local disks...

[BobPhoenix]

6 recording all going to the same local UNC path with a Pentium4 3.4Ghz and between 10-20% CPU usage based on task manager in my RDP connection so may have a small amount due to that.

BobP.

[salsbst]

10-20% usage total, or just for the Sage process?

[BobPhoenix]

Originally Posted by salsbst

10-20% usage total, or just for the Sage process?

Sorry that was total for the computer didn't look at the SageTV process itself. Another thing I forgot was this was with Service mode.

[salsbst]

It looks like 6.0.16 has fixed this issue for me. (Fingers crossed, knocking on wood.) I'm now hovering between 0-6% for the service process while recording on both of the PVR 500's tuners.