I'm using the video out on my PVR-350 which means I have no GL capabilities etc. I am not using the decoder in the card which probably would help but there are other issues that I do not like if I enable the decoder. Encoding (MPEG2) should all be handled by the card though. I'm not sure if I am using XvMC or not, how do I tell? I don't remember doing any specific configuration for that. If it wasn't enabled in the old RPMS by default and is enabled in the new RPMS by default that I would suspect that could be my problem as Xorg CPU is also very high during playback.
I don't remember what the CPU load was like prior to the update though. The updates should have been very minor. I think I was running .20-137 and now am running .20-141. I'm not 100% that the problem is actually in Myth. It could be another system utility or library in that yum.log update list that is causing the problem. Do you have a link to the thread you are referring to? It might give me some ideas. Thanks! --- DM - ATRPMS <[EMAIL PROTECTED]> wrote: > Increased CPU does seem to be a sporadic side effect > for some reason, > based on a couple posts here and a few more in > archived on other MythTV > oriented lists. (See my posts from a couple weeks > ago on this list.) > My frontend had significantly increased CPU after > upgrade (went from 50% > to 90+%) while still configured with XvMC. Since > CPU loads like that > cause lockups on that hardware, this is a problem! > I had to completely > retweak the playback without using XvMC (which A> > didn't work before - > that's why i went to the trouble of XvMC to begin > with; and B> better > performance is after all the purpose of XvMC) to get > it working again. > > The backend system (which is a backend/frontend > combo) had no such > issues that I've noticed so far. > > I would be curious to know A> if you are using XvMC > and B> what your > video card is (my problem box is an nVidia). (Not > that I'll probably be > of much help, but I'm curious. :) > > I have not paid attention to transcoding jobs, so I > can't help you > there. You probably have done this already, but if > not you may want to > get a baseline on the server when you are just > recording (not playing > back) to make sure it's not the encoding functions > that are getting > you... If your encoding usage is higher, the > backend may have enough > CPU to encode it and stream it (i.e. to a frontend > system), but not > encoded it and then decode it again (i.e. watching > directly on the backend). > > Dan > > Axel Thimm wrote: > > On Wed, Oct 11, 2006 at 05:30:05PM -0700, Void > Main wrote: > >> I built an FC5 MythTV box back on the 16th of > September and updated > >> it with all the latest updates and used MythTV > RPMs from ATrpms. > > > >> I realized the MythTV RPMS had been updated to > newer version in the > >> repository so I thought no problem, I'll just > "yum update" on the > >> MythTV server and upgrade everything to the > latest. Well, the remote > >> frontends seem to still work find with the newest > MythTV updates but > >> the main box that servers as both the frontend > and backend now has > >> choppy video most noticable when trying to watch > live TV and seems > >> to be worst when on screen menus are visible. > It's like a stutter > >> every few seconds. > >> > >> It is as if the frontend is now taking more CPU > than it did before > >> the upgrade. I have also done a couple of > transcodes since the > >> upgrade and these also seem slower. I was getting > over 20 frames per > >> second when transcoding (~25fps if I recall) and > now I get less than > >> 20fps (~17fps). > > > > Is that with or w/o myth running and eating CPU > time. If it's with > > it's no surprise, any process will be slower if > something is eating > > away all of your CPU. If it's w/o it gets > interesting, as watching > > live tv and "transcode" share almost nothing in > common. > > > >> I am curious if anyone else has run into this > > > > Yes, that would be an important information. > > > > FWIW the updated packages only contain fixes from > the -fixes > > branch. I can't really think of something in there > that starts slowing > > down your system, though, and indeed there were no > similar reports > > yet, but let's see. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ atrpms-users mailing list [email protected] http://lists.atrpms.net/mailman/listinfo/atrpms-users
