> > > 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 188.8.131.52. 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.
> Did some tests, without conclusive results so far.
> Upgraded to xine-lib 1.2 from hg - same results (both for xine and
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 184.108.40.206 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...
> Goga, you're with S2API drivers, right?
exactly, with hvr4000
On our Russian forums there's some statistic with
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
have you some comments about it ?
could you try with vdr-xine ?
vdr mailing list