CPU pegs when recording

[lohmein]

Hi everyone,
I've got a P4 1.4 GHz TiFaux running Sage 5.0.4. I've never had this problem before, but recently the box SageTvService.exe has been pegging out at 100% ever 2-3 seconds when it's recording something. I have 3 tuners in my box, and there used to be no problem when recording 3 things at once, at least as far as smooth video play went. Now, with the CPU pegging, the video stutters ever 2-3 seconds. Very problematic, as you can imagine. I have recently moved to NYC, and have had to acquire an STB. If this (and the USB-UIRT I use to control it) are a problem, please let me know. But I don't think that should be the issue. If it were running at a steady percentage, that would be one thing. But my SageTvControl.exe now bounces between 100% and 10-30%. It makes no sense. Please help me fix this, so I can use Sage even when it's recording something. Thanks, Lance.

[Opus4]

Check the hard drives -- did something cause thei access speed to diminish? I've seen posts in the past where the DMA mode (or whatever it was called) got set to a slower setting. Or, at least that's one guess.

Or, it isn't trying to record to a drive that isn't formatted w/64K cluster sizes, is it?

- Andy

[lohmein]

Yes, I have 64k clusters on my recording drives.

How do I check/change that DMA setting?

[polen]

Should be under your Windows Device Manager. Look for the IDE controller section.

-Polen

[lohmein]

Checked it under the IDE/ATAPI controllers; everything was already set to "DMA if Available".

Ok, right now I'm recording 2 things at once, and everything's fine. I'm even watching something, and it's great playback. 2 hours ago I was recording 1 thing and the CPU usage was bouncing around. I have no idea why it's suddenly fine, nor do I know if it'll hold. Any thoughts?

Edit: The problem began again precisely at 11pm. I believe the problem only occurs when the tuner that is associated with my STB is recording (I have 3 tuners, 2 use analog and the third uses USB-UIRT to control my STB). Has this sort of thing ever happened to anyone before?

[mdnttoker]

lohmein: Are you using the sageTV service or app?

I've had a problem recently where the sageTV service starts eating up 50 - 90% of my CPU time (An Athlon 3200+), and if I open up the SageTV window, it comes up black.

If I shut down the service, & reboot windows, everything works fine again or awhile.

I've started using the SageTV app alone (without the service). We'll see if that makes a difference...

[lohmein]

I'm using it as a service. I think I experienced your problem before. Are you running Sage in Full Screen Exclusive mode? If so, turn it off (Setup -> Detailed Setup -> Advanced). I had a similar issue and turning FSE off fixed it for me; maybe it will help you.

And I stand corrected from earlier. The tuner connected to the STB is the only one I can record on and NOT get the CPU problems. Recording on either of the tuners with analog signals results in CPU usage bouncing up and down. I tested each tuner individually and jointly with the others; that's definitely the root of it. Anyone have an idea?

[mdnttoker]

Originally Posted by lohmein

I'm using it as a service. I think I experienced your problem before. Are you running Sage in Full Screen Exclusive mode? If so, turn it off (Setup -> Detailed Setup -> Advanced). I had a similar issue and turning FSE off fixed it for me; maybe it will help you.

And I stand corrected from earlier. The tuner connected to the STB is the only one I can record on and NOT get the CPU problems. Recording on either of the tuners with analog signals results in CPU usage bouncing up and down. I tested each tuner individually and jointly with the others; that's definitely the root of it. Anyone have an idea?

Have you tried swapping around the cards and/or re-assigning IRQ's in the BIOS?

[polen]

Make sure you have Java 1.4.2_11. This can be seen under the Java icon in the control panel. If it's 1.5 Update 6 then uninstall it and you should be back to 1.4.2_11. Also, under the Java Control Panel, turn off the update feature.

-Polen

[lohmein]

Rolled back to java 1.4.2_11, and everything seemed to work alright over the weekend, but now i'm getting the same problem. Anytime the sage tv service is recording on an analog tuner, the CPU usage is bouncing up and down severely. Update is turned off. Don'tknow what is going on; never had this problem before in the 2+ years i've been using sage. Other thoughts?

[Paul365]

Hi,

What tuners are you using?
Are they Hardware assisted or software only?

How is the STB Connected/Captured? and is it Hardware or software encoded?

Has your virus scanner recently upgraded the engine, or maybe you have picked up some spyware?
Have you looked over the processes running in the Taskmanager, maybe there is something new there that you don't recognise thats affecting things.

Sorry for stating some of the obvious fixes, but sometimes we can overlook the simple in search of the complicated.

[lohmein]

Heh, no problem with the obvious fixes; I'd love one.

Using 3 Hauppague PVR-250s, all about 2-3 years old, so all hardware encoding. The STB is connected to one of the tuners (the one with the remote connection in the back - is that the MCE type?). The STB is connected to the tuner via regular cable, and the tuner is set to sit on channel 3 and use USB-UIRT with 56k sensor to transmit signals to the STB.

Ran a virus and spyware scan earlier; came up clean. Been watching the processes in task manager the past few days; the only ones that get to or stay at the top are SageTvService.exe and the system idle process.

Would a log file help anything here? I mean, sage isn't crashing or anything, just eating up a bunch of cpu. Would there be helpful information in there, or does it just log crash information and commands and such?

Again, thanks for all the help ya'll : )

[Paul365]

Is your virus scanner active in memory all the time? or maybe you have an active anti-spyware program, You could try unloading them if so, maybe a recent auto upgrade has started to interfere with the files as they are written.

How many items are in your system tray? are there any that can be removed? Is your O/S up to date.

What about a firewall, I've known systems take a plunge every few seconds because someone from the outside is knocking on the door of a network service, or the reverse, some service or utility is phoning home or polling all the time.

[lohmein]

I've got an active virus protection (symantec corporate), but i've had it for years without a problem. I've tried disabling it and it doesn't affect anything; rtvscan.exe hasn't been popping high up on the processes list either as far as cpu usage goes. No active spyware protection pretty much to avoid this cpu problem.

Only things in the tray are my nvidia graphics card icon, the IR icon, and the antivirus icon.

Windows firewall is active, but I don't think it's a problem. I'm behind a linksys router/firewall, so I believe that blocks most problematic traffic.

Something I noticed today, it's almost as if the CPU time is being allocated incorrectly. Video playback alone without any recordings ran the CPU at around 60%, and even then i kept getting a little stutter in the sound. Heavy processes don't seem to ever be sharing CPU time, but eating it up as much as possible. don't know if that makes any sense there ; ) Is there any way to test/check something like that?

My biggest issue is that I can't think of anything that's changed recently. If I'd done an update, or added a program, it would make sense. But other than adding in that STB programming a few weeks ago, I've done nothing with it other than try and use it.

Thanks again for all ya'lls help!

[lohmein]

Ok, figured out the problem. Opus4, you were right. The problem was with the hard drive access speeds. It wasn't an analog vs. STB connected tuner issue, it was what hard drive they were writing the files to issue (I've got 2 in my box, and only 1 had the problem). Explains the inconsistency, and the stuttering on the video playback.

One of the drives had gotten bumped down to PIO from UDMA5. It was still set to use "DMA if Available", which is why I overlooked it the first time around, but the actual speed it was using was PIO. Did some research, apparantly if your HD has 5 or 6 UDMA transfer errors, windows automatically bumps it down to PIO and it stays there. Won't change it back. I had to uninstall my Primary IDE controller through the Device manager and restart windows in order to get it to reinstall and refresh. Worked like a charm; now I'm back running on UDMA5 on that drive and everything's great.

So again, thanks for everybody's help with this; I probably never would have looked at that stuff on my own. I really appreciate it. Hope this solution can help somebody else in the future : )

[Bryann]

Originally Posted by lohmein

Ok, figured out the problem. Opus4, you were right. The problem was with the hard drive access speeds. It wasn't an analog vs. STB connected tuner issue, it was what hard drive they were writing the files to issue (I've got 2 in my box, and only 1 had the problem). Explains the inconsistency, and the stuttering on the video playback.

One of the drives had gotten bumped down to PIO from UDMA5. It was still set to use "DMA if Available", which is why I overlooked it the first time around, but the actual speed it was using was PIO. Did some research, apparantly if your HD has 5 or 6 UDMA transfer errors, windows automatically bumps it down to PIO and it stays there. Won't change it back. I had to uninstall my Primary IDE controller through the Device manager and restart windows in order to get it to reinstall and refresh. Worked like a charm; now I'm back running on UDMA5 on that drive and everything's great.

So again, thanks for everybody's help with this; I probably never would have looked at that stuff on my own. I really appreciate it. Hope this solution can help somebody else in the future : )

Wow! You just completely solved the problem I was having over the last few days. Sure enough, my recording drive had fallen back to PIO. I'm definitely ordering that new SATA drive I've been considering now to prevent that from happening again.