You're saying that kernel provided by distributors (Fedora 10 in my case)
is
not tuned for desktops? Interesting... Will try that after I'll try moving back to 1.7.0.
I'm not agreeing that tweaking your kernel will help channel tune times because I don't know. I can just confirm that your times seem excessive. I don't know if this helps but I'm using Debian testing with a v4l tree from 2008-09-17 (pre-s2api mess), VDR-1.7.1, and kernel 2.6.27.8. I don't use a stock kernel, I've compiled my own containing only what I need. If you think it will help, I'll be more then happy to send you my .config to try.
Hi,
Did some tests, without conclusive results so far.
Upgraded to xine-lib 1.2 from hg - same results (both for xine and xinelibout).
because xine-lib 1.2 didn't update 2 months I have installed xine-lib-1.1 branch from hg
Tried to compile softdevice 0.5, but it doesn't work with current ffmpeg (also from SVN not long ago).
for me too
Tried softdevice from CVS, now it compiles, but crashes.
for me too
I still prefer external frontend, but want to know what cause the delay... Compiled now 2.6.27.8 kernel with desktop preemptive model (I think it was the default by th way) - same results.
VDR User, I will be mor than happy to see your .config to compare with mine, maybe I've missed something.
My next step would be to move to 1.7.0, but I suspect it will not help since Goga777 reports the same problem...
yes.
Goga, you're with S2API drivers, right?
exactly, with hvr4000
On our Russian forums there's some statistic with http://www.forum.free-x.de/wbb/index.php?page=Thread&threadID=202
1. vdr 1.6.0 and em84xx - switching time less than 1 sec 2. vdr 1.7.1 softdevice, directfb - 1-2 sec 3. vdr 1.7.0 eHD - 1 sec 4. vdr 1.7.0(1) xineliboutput, directfb - 2-3 sec, xineliboutput, x11 - 2-4 sec
seems it's due to of tcp/ip and pipes which are using xineliboutput
@Petri have you some comments about it ?
@Alex could you try with vdr-xine ?
Goga