If your worried about the wake up delay for the frontend you could try
using the piece of software I've written to get round this very problem.
Its not quite as simple as typing xine dvb://<Channel Name> but its not far
off.
Have a look at http://dvbstreamer.sourceforge.net, if you use dvbstreamer to
send the channel to udp port 1234 you can then simply type xine
udp://localhost:1234 , and then select the channel you want to watch in
dvbstreamer (you don't even need to close xine to change channels).
It keeps the tuner open all the time and constantly monitors the PSI/SI for
the current multiplex so it always up to date, and only retunes when the
selected service is not on the current multiplex.
Cheers
Adam
From: Barry Scott <barry.scott@xxxxxxxxxxxx>
To: Hartmut Hackmann <hartmut.hackmann@xxxxxxxxxxx>
CC: linux-dvb@xxxxxxxxxxx
Subject: Re: TDA10046H very slow to tune
Date: Wed, 16 Aug 2006 13:47:12 +0100
Hartmut Hackmann wrote:
Hi, Barry
Barry Scott wrote:
I'm noticing that the KWORLD DVB-T 220 with the
TDA10046H tuner is very slow to tune 2 to 5 seconds.
Cards like the AverMedia 771 tune in less then a second.
Is this a problem with the driver or the chip?
Barry
This is not normal, do you use a recent version of driver and firmware?
I'm using a snapshot pf HG from 27-Apr-2006.
Will latest code help with this problem?
The tuning takes about 0.5 seconds. With good signals, the TDA10046
locks within a second. You need to add the time for the DVB application
to fill its buffers and to find an I-frame. This is longer but the same
for all cards.
I'm working with xine and its input_dvb.c code. Its debug messages
show the progress of the locking. I'm reporting the time it take the driver
to report via its status ioctl that its locked. I'm not counting the time
it
takes to then receive enough DVB-T packets to play on the screen.
But: the first lock in a session (open dvb device) always takes longer
becase the chips need to recover from sleep mode, check and download the
firmware and determine some parameters. This is partly intention, partly
chip behaviour.
This could be the problem. In xine it will open the dvb device and tune it,
which will always hit the this problem. How can I confirm that its the
wake up from sleep and firmware reloading that is the delay?
How can the driver be changed to avoid the sleep and reload
of the fireware? I need to find a fix for this problem.
If the lock always takes longer, this might be due to poor signal quality.
Signal quality is good.
Updating the firmware might help.
There also is one special issue with the TDA8275a silicon tuner: Due to
its pinciple, it is sensitive to strong transmitters on another channel.
Classic tuner "cans" handle this better.
How close does the frequency of the other channel have to be for this
to be an issue?
Barry
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
