High CPU/memory usage when idle - likely to improve? (1 Viewer)

[Flash]

Area: Media Portal Program
MediaPortal Version: 0.2.0.0-SVN-10.09.2006-10:43:46,41-Build 10220
(2006-09-10)
MediaPortal Skin: BlueTwo
Windows Version: Windows XP (SP2)
.NET CLR Version: 2.0.50727
DirectX Version: 4.09.00.0904 (9.0c)
Audio Codec: MPA Decoder Filter
Video Codec: MPV Decoder Filter
CPU Type: AMD Athlon XP 2400+
Memory: 511 MB
Motherboard: NF7-S/NF7,NF7-V (nVidia-nForce2)
TV Card Model: Huappauge Nova-T
TV Card Type: DVB
TV Card Driver: -
Video Card Model: Nvidia Geforce4 TI 4200 (microsoft Corporation) (128 MB)
Video Card Driver: -
Video Card Resolution: 1024x768
Video Render Type: -
Audio Card Model: AVerMedia DVB-T TV Tuner (A16AR)
Audio Card Driver: -
Synopsis::

Very high CPU usage. Found in multiple mediaportal versions from latest svn from to 0.2.0.0 (stable)

Symptom: Every minute Mediaportal.exe uses 90-95% CPU for a period ranging from 17 seconds (fastest system) to 50 seconds (slowest). It does this every minute regardless of other operations. (Ie, Recording single or double tuners, or just sitting idle)

Problem verified on three PC's (32bit XP2400, 64bit 3200 and an Intel 2.2ghz celeron, with memory ranging from single 512mb dimm to a system with 2gb, on a variety of hdd's, abit and asus motherboards)

I suspect problem may be narrowed down to TV Schedules as on a new install MP behaves normally. It is only when new schedules are imported that this huge CPU demand starts. What is called every minute?

Things I've tried with no effect:
Turning off "Get EPG via DVB"
Removing both TV cards.
Multiple reinstalls, always reinstall from scratch after uninstalling.
Keeping only 7 days' schedules.
Unloading ALL by "My TV" plugins.
Ensuring no other programs are running.

Also, when running TvGuideScheduler when importing listings, both it and MediaPortal.exe use 100% cpu for a long time (30 minutes or so) AND astounding amounts of memory. I've clocked TVGuideScheduler allocating 1.6GB of RAM (forcing a resize of the pagefile). I have about 20 channels enabled (UK Freeview) with up to 14 days schedules.

In MP, TV -> Scheduled programs. If I click "Cleanup" after five minutes of 100% usage, I get the "x schedules removed, OK" button - but MP continues using 100% cpu until forcibly closed (request close is ignored - I've left it working for 2 hours just in case)

These problems have been with me since I started using MP some six or so months ago and since I am only using it to record DVB programs, I'm disappointed the demands on the system are so huge. I can understand these things if what it was doing at the time was demanding - like displaying video, but it's just sitting there counting seconds until it's ready to start recording.

Please tell me if there is any hope if improvement with this high CPU usage when idle and when importing the tv schedules, and big demands on different systems with little in common with each other apart from the dvb cards. I love MP and its' hardware support has been superb, but this is driving me nuts!

 

[rtv]

Video Card Model: Nvidia Geforce4 TI 4200
That's the typical symptom for machines not meeting the minimum requirements.

Get a DX9 capable gfx board and you'll see cpu usuage almost always < 10%

 

[Flash]

As I said, it's the same for three machines, one with a very fast nvidia card - none of which matters as it's only recording and gives this issue even when minimised to the system tray, thus using no graphical output.

There is no common hardware between any of the machines other than the tuners, and the issue still occurs when they're removed from mediaportal. It's not the hardware.

 

[Taipan]

I realise that this reply is not very helpful, but I can't reproduce the problem you describe on my PC. Which suggests that its something to do with your setup - all 3 of them.....but I have no idea what that might be...


You have suggested what the problem might be:-

I suspect problem may be narrowed down to TV Schedules as on a new install MP behaves normally. It is only when new schedules are imported that this huge CPU demand starts. What is called every minute?

How are you grabbing the EPG data and importing it into MP?

 

[Flash]

Using xmltv, and I've tried with and without "Grab epg from dvb" ticked. No difference.

To compare, I've today installed GB-PVR. Although not as simple to set up as Mediaportal, it's now working very well. CPU Usage? Less than 5% on the 2400 with no spiking, with less memory than MediaPortal too, using exactly the same Xmltv source file. Importing fresh EPG takes about 20 seconds and doesn't hammer the system anywhere near as much. Also o note is that MP took between 3 and 10 seconds to change channels, whereas GB does it instantly, on the same hardware using the same BDA drivers. The Hauppuage and Avermedia own utilities also change immediately too. Odd.

A shame, as I really liked Mediaportal. It's a hell of a piece of software and an awesome project but this issue of resources has been with me from the start almost a year ago and I can't imagine how my configuration is different because I've reinstalled so many times and used the defaults as much as possible.

 

[Paranoid Delusion]

I would say post specifications for all three computers and we can see if anything specific jumps out, as again my usual CPU readings Recording/timeshifting with 2-3 dvb-t cards is sub 20%, but i use WebEPG.

 

[Taipan]

I am sorry flash, but I still don't understand how you are creating the EPG - you just say "using xmltv" - but I wanted to know what method / tool / application you use to grab the EPG data and create the "TVguide.xml" that MP then reads into the TV database?

For example, I use WebEPG, and since it is scheduled to run just once a week (in the afternoon), then there is no impact on MediaPortal. The loading of the new EPG data into the TV database file then only takes a few seconds.

Could you please describe what method or process you are using to create your EPG, as this seems to be the issue causing the high CPU and memory usage?

BTW, you will notice that nobody else has reported the same problem, so it does seem to be something unique to your configuration/s....