Skin BlueTwo wide - High CPU Load (1 Viewer)

[grubi]

I also just installed 7.9 and have the problem as well. Tried on an x1950pro and 2x x1300 machines and they all now exhibit the problem.

I would strongly encourage you to open a case at ATI. They told me that as long as no additional people report the same issue they regard it as an isolated problem and will not investigate further.

Use this link and create an account:

http://support.ati.com/ics/support/default.asp?deptID=894

Then you could reference to ticket 737-1256682 which I laready opened for this issue.

Regards,
grubi

 

[allanp81]

grubi, that link's broken.

 

[grubi]

grubi, that link's broken.

Try this one:

http://support.ati.com/ics/support/default.asp?deptID=894

 

[Andrew H]

Guys... I have a related issue with my AIW 9600XT on a 3100+ when I try to use any 16:9, or wide skin. ONLY the narrow (BlueTwo) skin works 100% right, when I select a wide skin I get pixelated MP graphic (border) around the TV frame, the BIG (main page) icons, and text in the TV Guide. I can return to the main page, resize and it's corrected for a while but returns after navigating around - especially to TV. I can NOT resize with the TV open because MP will just hang. Here's the punch line: I'm still running Catalyst 5.4 because I want to retain MMC 9.06.1 to do A/V capture. I suspect I could use a later Catalyst, like 5.13 or 6.3, to address the MP corrupt wide display issue, as long as I stay away from their latest releases.

I'd read on rage3d to use the WDM 6.14.10.6325 and mine's still using 6.14.10.6300

I'd bet the high CPU and my corrupt display issues are related... any suggestions, directions, observations or comments would be appreciated. Oh, and this is the FIRST issue I've seen with my HTPC that points at my old drivers... I use WatchHDTV with both my HDTV-Wonder and Hauppauge 1600 just fine.

 

[maxxess]

Visited a friend at a party tonight, who had problems with X.264 playback.
We did not solve the X.264-problem but I noticed one thing the owner never noticed. In idle mode (main menu) Mediaportal use ~80% CPU on the Dell SC1600 server with Xeon CPU and a ATI Radeon 9250/128 mb PCI-card (system running XP pro).

The latest (XP) driver for the radeon 9250 is from 2006(!) and experience the same problem as has been reported with brand new cards and Catalyst's which are years newer (currently all above 7.4).

Seeing that newer ATI-cards get the "MP-bug" implemented, seeing two years old drivers having the same bug for another radeon family, I wonder how many actually are affected but never notice? (like the friend I visited)

MP is the only app which has problems with *my* ATI X1250, wasting 100% CPU when in main menu. The problem started with 0.2.3 RC1 (which everone wants since powerscheduler is broken in 0.2.2).

Any developer who has a clue? How do we troubleshoot to provide info?

Nobody want a 0.2.3 "rtm" which may or may not be incompatible with a vast number of computers containing ATI-cards?

 

[rav994]

why is this clasified as a non bug as the forum is flooded with this issue

 

[spacexion]

Hi all.

Same problem for me but with a rather older card!

ATI Radeon 9000Pro vivo and Catalyst 6.5
100% cpu in use while MediaPortal was idle on default skin interface, and normal CPU usage (40/50% average) while playing videos.

I installed more recent "Omega" available for this graphic adapter (3.8.252) and this fixed the issue.

I agree with rav994 that it's clearly a MediaPortal bug, as these ATI cards with Catalyst are working fine for any other purpose (video playing, games, rendering, etc...) and fail only in managing MediaPortal interface.

Anyway, I installed Media Portal first time this morning, and it's definetely a great piece of software!

 

[lapa]

2003 also

hello,

i know it's not official, but i also suffer from 100% cpu loads.

fresh installed windows 2003 sp2 + hotfix + dotnet 3 (with xp sp2 sbe.dll & sbeio.dll)
mediaportal 0.2.3.0 rtm and 02.02.2008 svn (tried this svn to get rid of the 100% cpu of the rtm)
abit radeon 9600xt 256mb with ati catalyst 6.12 inf install
abit nf7-s v2 (nforce2) with athlon xp 2600+
skystar 2 dvb-s rev 2.8 with 4.4.1 non-bda drivers
mp is running 24/7 on the secondary display with blue wide skin

the symptoms are strange. mp is used exclusively for movies and tv. both divx / 720p / dvb-s tv content is diplayed correctly, everything works fine. as i am working on the pc the same time i noticed some lagging. the lags come sometimes without any interaction with mp. p.e. 10 minutes ago i had constant 100% cpu while watching tv, from that time on i just googled "mediaportal cpu load". now its back to the normal 40-50% (running at 1ghz), without touching / remoting mp. mp uptime is currently about a day, with several hours of active tv / movie watch. the first symptoms were some shorter lags on the start screen, about 10 seconds in irregular intervals. i did not test omega drivers and don't plan to if there is some other fix to this.

there is nothing much i can add, i hope it helps somewhat.

 

[lapa]

i have tested the current recommended omega drivers (3.8.442) but the problem still exists/ed.

i switched then to debug logging and closed mp during one of the 100% cpu time periods (which already lasted over several minutes then). i got the attached log showing epg grabbing. so i switched off the "grab epg from dvb" option. from that on (means in the last few hours) i have no 100% cpu times.

some more information on the issue:

thread causing: mscorwks.dll!CreateManagedInstance+0x8aa4

at normal operation (being idle) the thread mscoree.dll!CorExeMain causes also 5-10% cpu time. this is a static "feature" even for the start ui. i don't like this either...

 

[lapa]

epg

i think i found the reason for my cpu loads:

2008-03-27 21:47:39.730966 [Info.][5]: epg-grab: EPG parsing...

the last days i was monitoring mp activity and found (almost) always the upper log entry at the start time of the cpu peaks. currently i have about dvb-s 20 channels, and the last peak lasted for about 1 minute.

i am not sure though, as there were also far longer peaks (10+ mins) and there were some time peaks with no epg parsing entries around...

anyway the epg parsing looks weird, as sometimes it lasts only 5-10 secs to complete, and sometimes it takes several minutes... it surely should run on low priority somehow instead of the high prio of mp.