[mythtv] Ticket #1049: DVBSignalMonitor needs to be able to monitor NIT/SDT

Daniel Kristjansson danielk at cuymedia.net
Wed Jun 7 03:02:09 UTC 2006


On Tue, 2006-06-06 at 22:32 -0400, Yeasah Pell wrote:

> When the diseqc stuff I'm working on is ready (it's getting close), that 
> will help with the rotor issue, since the code will know approximately 
> when the rotor is done rotating, and can issue another tune request at 
> that point. I think that's a better way to handle the need for 
> subsequent tuning commands than the retuning hack.
Other than the absolute ugliness of the hack, this was another reason
I wanted to get rid of this code. I want to give efforts like your
DiSEqC code a clean slate with which to work.

> There may be other reasons to do retuning besides rotors though -- for 
> example, the retuning code itself talked about some buggy DVB-C hardware.
I think the DVB-C problems are handled by all those i2c usleep hacks
I added on that same ticket. There are two common problems with the
broken DVB drivers: one is missing semaphores, and the other is i2c
bus flooding. The 10 ms sleep after each frontend set is intended
to help when the driver writer forgot to make sure frontend sets
are processed before later frontend gets; i.e. the missing fence
problem. The 50 to 300 ms sleep between each frontend get is to avoid
the i2c bus flooding, this hack is for when the driver writer doesn't
[properly] rate limit i2c commands.

The fact that you can write DVB drivers that exhibit the missing fence
problem is a very serious design flaw in the DVB API. I would really
prefer to have MythTV refuse to run with drivers that exhibit this
problem. Unfortunately the popular Nova-T has such a broken driver
so the 10 ms sleep is needed for now.

The problem with i2c flooding is a more understandable problem.
This can happen because the drivers had to be reverse engineered
or the data sheets were missing important timing information.
Even if the driver writer makes sure the driver works on their
own system, it may still fail on someone else's system.

Both problems are difficult for the DVB driver maintainers to fix
because they don't have most of the hardware they support. This
can be compared to our support for the DBOX2 and similar esoteric
hardware which none of the regular MythTV developers use or even
have access to. The DVB maintainers depend on inexperienced or first
time driver writers to both write and test the drivers. What is
needed is a test harness that subjects new drivers to grueling
timing tests which the driver authors can use to self test their
drivers.

-- Daniel



More information about the mythtv-dev mailing list