Hi all,
Another question to bother you...
How long does it takes to switch a FTA channel on your system? In my case DVB-S.
I wonder if this timing sounds ok to you (I think its kind of slow): 1.7.1 + ext64-livebuffer + xinelibout
2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later.
Please let me know what is your status on that (including version you're using).
Thanks.
On Fri, Dec 5, 2008 at 11:05 AM, Alex Betis alex.betis@gmail.com wrote:
2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later.
Sounds long, I can channel change on DVB-T and DVB-S almost instantaneously.
You can normally fix this by recompiling your kernel with low latency settings (timer frequency, kernel queuing methods etc) - normally selecting the best settings for a desktop helps.
On Fri, Dec 5, 2008 at 11:34 AM, Morfsta morfsta@gmail.com wrote:
On Fri, Dec 5, 2008 at 11:05 AM, Alex Betis alex.betis@gmail.com wrote:
2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later.
Sounds long, I can channel change on DVB-T and DVB-S almost instantaneously.
You can normally fix this by recompiling your kernel with low latency settings (timer frequency, kernel queuing methods etc) - normally selecting the best settings for a desktop helps.
I agree. My channel changes are about 1 second regardless if I'm switching on different transponders or lnbs.
On Sat, Dec 6, 2008 at 12:58 AM, VDR User user.vdr@gmail.com wrote:
On Fri, Dec 5, 2008 at 11:34 AM, Morfsta morfsta@gmail.com wrote:
On Fri, Dec 5, 2008 at 11:05 AM, Alex Betis alex.betis@gmail.com
wrote:
2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is
playing
right after the switch, image is shown, but start moving about 1 more
second
later.
Sounds long, I can channel change on DVB-T and DVB-S almost
instantaneously.
You can normally fix this by recompiling your kernel with low latency settings (timer frequency, kernel queuing methods etc) - normally selecting the best settings for a desktop helps.
I agree. My channel changes are about 1 second regardless if I'm switching on different transponders or lnbs.
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.
Thanks.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, Dec 5, 2008 at 9:37 PM, Alex Betis alex.betis@gmail.com wrote:
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.
On Sat, Dec 6, 2008 at 5:01 PM, VDR User user.vdr@gmail.com wrote:
On Fri, Dec 5, 2008 at 9:37 PM, Alex Betis alex.betis@gmail.com wrote:
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). Tried to compile softdevice 0.5, but it doesn't work with current ffmpeg (also from SVN not long ago). Tried softdevice from CVS, now it compiles, but crashes. 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...
Goga, you're with S2API drivers, right? Halim and Morfsta, how about you? VDR User doesn't use S2API drivers...
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi Alex, If you are using debian, yur can use the ffmpeg shipped with lenny. This version of ffmpeg work for me with softdevice. Gruß Halim
On Thu, Dec 11, 2008 at 12:03 AM, Halim Sahin halim.sahin@t-online.dewrote:
Hi Alex, If you are using debian, yur can use the ffmpeg shipped with lenny. This version of ffmpeg work for me with softdevice.
I use Fedora Core 10.
You did not answer what driver do you use? S2API or multiproto?
Gruß Halim
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
On Thu, 11 Dec 2008, Goga777 wrote:
- 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
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 rahrenbe@cc.hut.fi
On Thu, 11 Dec 2008, Goga777 wrote:
- 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
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.betis@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 rahrenbe@cc.hut.fi
On Thu, 11 Dec 2008, Goga777 wrote:
- 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
On 12/12/2008, Alex Betis alex.betis@gmail.com 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?
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 Fri, Dec 12, 2008 at 4:47 PM, Theunis Potgieter < theunis.potgieter@gmail.com> wrote:
On 12/12/2008, Alex Betis alex.betis@gmail.com 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.
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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?
is it possible to use --verbose option for local frontend
./vdr -c /etc/vdr/ -P xineliboutput
I couldn't run it with --verbose option
I don't use any remote frontends
btw - I corrected the my diseqs.conf
from
S36.0E 00000 V 10750 t v W15 [E0 10 38 F4] W15 t S36.0E 99999 V 10750 t v W15 [E0 10 38 F5] W15 T S36.0E 00000 H 10750 t V W15 [E0 10 38 F6] W15 t S36.0E 99999 H 10750 t V W15 [E0 10 38 F7] W15 T
to
S36.0E 00000 V 10750 t v [E0 10 38 F4] S36.0E 99999 V 10750 t v [E0 10 38 F5] T S36.0E 00000 H 10750 t V [E0 10 38 F6] S36.0E 99999 H 10750 t V [E0 10 38 F7] T
and the switching time decreased
Goga
Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions.
Thanks.
2008/12/11 Rolf Ahrenberg rahrenbe@cc.hut.fi
On Thu, 11 Dec 2008, Goga777 wrote:
- 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,
On Sat, Dec 13, 2008 at 3:53 PM, Goga777 goga777@bk.ru 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?
is it possible to use --verbose option for local frontend
./vdr -c /etc/vdr/ -P xineliboutput
try ./vdr -c /etc/vdr/ -P'xineliboutput --verbose'
I couldn't run it with --verbose option
I don't use any remote frontends
btw - I corrected the my diseqs.conf
from
S36.0E 00000 V 10750 t v W15 [E0 10 38 F4] W15 t S36.0E 99999 V 10750 t v W15 [E0 10 38 F5] W15 T S36.0E 00000 H 10750 t V W15 [E0 10 38 F6] W15 t S36.0E 99999 H 10750 t V W15 [E0 10 38 F7] W15 T
to
S36.0E 00000 V 10750 t v [E0 10 38 F4] S36.0E 99999 V 10750 t v [E0 10 38 F5] T S36.0E 00000 H 10750 t V [E0 10 38 F6] S36.0E 99999 H 10750 t V [E0 10 38 F7] T
I have 8-1 disecq switch that requires 2 commands to be sent (commited and uncommited), so my case even more complicated :( But I think your change saves about 50 mSec (30 you removed and few more that driver add for every command sent).
and the switching time decreased
Goga
Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions.
Thanks.
2008/12/11 Rolf Ahrenberg rahrenbe@cc.hut.fi
On Thu, 11 Dec 2008, Goga777 wrote:
- 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,
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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?
is it possible to use --verbose option for local frontend
./vdr -c /etc/vdr/ -P xineliboutput
try ./vdr -c /etc/vdr/ -P'xineliboutput --verbose'
I have already tried so , wrong argument Hereafter you can find the explanation from xineliboutput author
============================================================= In local mode logging level is controlled by VDR. Verbose logging is enabled when it is enabled in VDR, as was in your log attachment. - Petri =============================================================
I couldn't run it with --verbose option
I don't use any remote frontends
btw - I corrected the my diseqs.conf
from
S36.0E 00000 V 10750 t v W15 [E0 10 38 F4] W15 t S36.0E 99999 V 10750 t v W15 [E0 10 38 F5] W15 T S36.0E 00000 H 10750 t V W15 [E0 10 38 F6] W15 t S36.0E 99999 H 10750 t V W15 [E0 10 38 F7] W15 T
to
S36.0E 00000 V 10750 t v [E0 10 38 F4] S36.0E 99999 V 10750 t v [E0 10 38 F5] T S36.0E 00000 H 10750 t V [E0 10 38 F6] S36.0E 99999 H 10750 t V [E0 10 38 F7] T
I have 8-1 disecq switch that requires 2 commands to be sent (commited and uncommited), so my case even more complicated :( But I think your change saves about 50 mSec (30 you removed and few more that driver add for every command sent).
I will watch on this
Goga
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?
is it possible to use --verbose option for local frontend
./vdr -c /etc/vdr/ -P xineliboutput
I couldn't run it with --verbose option
I don't use any remote frontends
btw - I corrected the my diseqs.conf
from
S36.0E 00000 V 10750 t v W15 [E0 10 38 F4] W15 t S36.0E 99999 V 10750 t v W15 [E0 10 38 F5] W15 T S36.0E 00000 H 10750 t V W15 [E0 10 38 F6] W15 t S36.0E 99999 H 10750 t V W15 [E0 10 38 F7] W15 T
to
S36.0E 00000 V 10750 t v [E0 10 38 F4] S36.0E 99999 V 10750 t v [E0 10 38 F5] T S36.0E 00000 H 10750 t V [E0 10 38 F6] S36.0E 99999 H 10750 t V [E0 10 38 F7] T
and the switching time decreased , till 2 seconds
Goga
Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions.
Thanks.
2008/12/11 Rolf Ahrenberg rahrenbe@cc.hut.fi
On Thu, 11 Dec 2008, Goga777 wrote:
- 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,
How long does it takes to switch a FTA channel on your system? In my case DVB-S.
I wonder if this timing sounds ok to you (I think its kind of slow): 1.7.1 + ext64-livebuffer + xinelibout
2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later.
Please let me know what is your status on that (including version you're using).
yes, currently I have the same situation as you. vdr 170 + cvs xineliboutput + svn ffmpeg
Goga
I don't know if this helps but I'm using the xine plugin, not xinelibout.
Hi Alex, Switching time with softdevice is great! I have tested all available soft output plugins but softdevice was the fastest regarding switching time. On my machine p4 2400 it is faster than my ff Card. I am using an skystar2 rev 2.6b with softdevice from cvs! HTH. halim
Switching time with softdevice is great!
nice to listen it
I have tested all available soft output plugins but softdevice was the fastest regarding switching time. On my machine p4 2400 it is faster than my ff Card. I am using an skystar2 rev 2.6b with softdevice from cvs!
which ffmpeg version are you using ?
Goga
Hi, On So, Dez 07, 2008 at 12:57:09 +0300, Goga777 wrote:
which ffmpeg version are you using ?
I am currently using svn-20080206-14 Some note about channelsettings: it speeds up the channelswiching Some note about channelsettings: it speeds up the channelswiching Some note about channelsettings: Don't use auto for inversion/coderateh setting. Insert the right vallues of the channel there. This speed's up switching a bit. regards Halim
-
Alex Betis -
Goga777 -
Halim Sahin -
Morfsta -
Rolf Ahrenberg -
Theunis Potgieter -
VDR User