Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams.
Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 90000 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 90000 / 25 ) Some documentation says something that large buffers are needed for "mosaic" channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. On Thu, Dec 11, 2008 at 11:23 PM, Alex Betis <alex.be...@gmail.com> wrote: > Gents, could you please run vdr-sxfe with "--verbose" flag and check if you > see the "prebuffer=" line in console output when you switch the channel? > > Please state the number you see there and please write again your vdr, > xine-lib and xinelibout versions. > > Thanks. > > > 2008/12/11 Rolf Ahrenberg <rahre...@cc.hut.fi> > > On Thu, 11 Dec 2008, Goga777 wrote: >> >> > 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 >> >> Well, I have vdr-1.6.0 and xinelibout-cvs with vdr-sxfe on my >> development setup using latest kernel drivers (S2API, DVB-T card) and >> haven't ever noticed as slow zapping as you documented: the channel >> switching time is about one second. >> >> BR, >> -- >> rofa >> >> _______________________________________________ >> vdr mailing list >> vdr@linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> > >
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
