On Fri, Dec 12, 2008 at 4:47 PM, Theunis Potgieter <theunis.potgieter@xxxxxxxxx> wrote:
On 12/12/2008, Alex Betis <alex.betis@xxxxxxxxx> wrote: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 )
so from 14400 to 128 lol, making it smaller helps with higher streams?
I wrote that special testing is needed for high streams, I didn't write that it helps it somehow.
I personally don't have HD channels available, so can't test myself.
As I also wrote, there is probably another buffer on the way (driver?), so it might be enough.
By the way, I'm more than sure there is a buffer in driver since scan-s2 gets messages from previous channel after it already tuned to a new one. At least with stb0899 (TT3200 and Twinhan 1041) driver.
I personally don't have HD channels available, so can't test myself.
As I also wrote, there is probably another buffer on the way (driver?), so it might be enough.
By the way, I'm more than sure there is a buffer in driver since scan-s2 gets messages from previous channel after it already tuned to a new one. At least with stb0899 (TT3200 and Twinhan 1041) driver.
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.
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
