Hi. I'm using VDR 1.3.37 with vdr-1.3.31-dvbplayer5.patch, vdr-1.3.37-sc.diff, vdr-1.3.34-ffdecsa-0.1.2.diff, vdr-femon 0.9.5, vdr-sc 0.5.3, vdr-xine 0.7.6, and xine-lib, xine-ui, both latest CVS snapshots with patches from vdr-xine 0.7.6. My DVB-S card is SkyStar 2.6D.
Although I have Athlon XP 2000+ with 512 MB RAM and GF3 Ti200, xine eats about 70-80, and even sometimes 90% of my CPU while displaying VDR's screen. I have followed tips from the xine FAQ but nothing changed. When I'm playing movies from my harddrive everything is ok. I have even tried launching the X server (X.org 7.0RC4) without window manager, still no efect. Can you help me, please?
Or maybe there is a way to use mplayer instead of xine?
Thanks in advance.
-- Jarek lt.munro@gmail.com
hi,
Alexander Munro writes:
Although I have Athlon XP 2000+ with 512 MB RAM and GF3 Ti200, xine eats about 70-80, and even sometimes 90% of my CPU while displaying
I had a similar problem. In my case, the problem was that I used the --stdctl (sp?) option. Since I did not start it from a terminal, there simply was no terminal from where to accept commands, but xine just kept trying to find one.
Problem was solved by removing the option, but as a downside, now xine shows the mouse cursor for a few seconds every time the picture size changes.
yours, Jouni
I had a similar problem. In my case, the problem was that I used the --stdctl (sp?) option. Since I did not start it from a terminal, there simply was no terminal from where to accept commands, but xine just kept trying to find one.
Problem was solved by removing the option, but as a downside, now xine shows the mouse cursor for a few seconds every time the picture size changes.
Nope. I run xine from a terminal and I don't use --stdctl. I forgot to say that xine produces a lot of "bad_frame" messages in the terminal. Maybe it has some meaning?
I've just run strace and it showed hundreds of:
ioctl(4, FIONREAD, [0]) = 0 select(5, [4], NULL, NULL, {0, 33000}) = 0 (Timeout)
and also (but not so many):
futex(0x8168ee4, FUTEX_WAIT, 809, NULL) = 0 futex(0x8168f18, FUTEX_WAKE, 1) = 1
I have no idea what it means but the former don't seem good, does it?
-- Jarek lt.munro@gmail.com
False alarm. I didn't noticed that xv output plugin had disappeared during xine rebuild (in the meantime my X.org changed version and location from /usr/X11R6 to /usr).
-- Jarek lt.munro@gmail.com