> > > 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  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 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

Reply via email to