[mythtv-users] DVB-T tzap versus mythtv 0.19

[Daniel Kristjansson]

On Sat, 2006-03-11 at 14:24 +0000, Robin Neatherway wrote:
> On 3/11/06, Doug Scoular wrote:
> > Hi All,
> >     I've upgraded to release-0.19-fixes (9277) and am still
> >     having problems with channel tuning and the Nova-T.

> I'm having similar problems, and I think the thread on LiveTV taking a
> long time is pretty much down to this Nova-T/0.19 incompatibility.
AFAIK

> DanielK, having said the driver is broken, can you please tell us what
> you think the problem is so I can go off and have a poke around. This
> is quite a problem for UK users as the Nova-T is a really common card
> over here and DVB is spreading more and more, especially among the
> kind of people who use Myth.
> What are the reasons behind the move away from the FE_HAS_LOCK change?
> Would some cards report this incorrectly? Maybe this could be made an
> option.

We haven't moved away from using FE_HAS_LOCK, in fact it is the 
only hardware info that has a threshold in dvbsignalmonitor.

The problem is that unless the hardware has finished tuning to
a new transport when we get the lock, the driver can report a
lock on the previous transport. To prevent this from happening,
we use FE_READ_STATUS, this should assure that the pending
tuning requests from the DVB driver's frontend are processed
by the DVB driver's backend. With the Nova-T this synchronization
appears not to work.

There are at least two other methods to assure that the tuning
request has completed.

DVB Events are sent by most drivers whenever the tuner changes
frequency. However in practice there are four problems with this
approach: first some drivers do not send the events, second the
event is not sent if the card already happens to be on the
requested transport, third some cards delete the events from the
event queue before we get a chance to see them, and fourth,
according to Aafloy, DVB Event notification has been deprecated
and so the problems won't be fixed.

FE_GET_FRONTEND works on some cards, in that it waits for pending
tune to complete before telling you about the tuning params. But
on at least one DVB card it doesn't work where FE_READ_STATUS does.
So far no card has been seen where FE_GET_FRONTEND works where
FE_READ_STATUS doesn't, so we don't do both.

After the FE_READ_STATUS, we fire up the dvbsignalmonitor, it waits
for an FE_HAS_LOCK, and then for the PAT & PMT tables matching the
values in the DB. Now if it waited on a matching SDT table instead,
it probably wouldn't be as huge a problem if FE_READ_STATUS returned
prematurely since SDT tables are presumably unique, unlike most
PAT and PMT tables.

-- Daniel