[mythtv] Errors in Mythtv-multirec...

[Endaf Jones]

On 7/8/07, Daniel Kristjansson <danielk at cuymedia.net> wrote:
> On Sun, 2007-07-08 at 12:20 -0600, Endaf Jones wrote:
> > On 7/8/07, Jochen Kühner <jochen.kuehner at gmx.de> wrote:
> >
> > > In the multirec branch i get this error:
> > >
> > > 2007-07-08 18:34:15.819 DVBChan(9:3) Warning: Your frequency setting
> > > (11836500) is out of range. (min/max:950000/2150000)
> > > 2007-07-08 18:34:15.819 TVRec(9): HW Tuner: 9->9
> > >
> > > but somtimes i can watch tv and sometimes not....
> >
> > I get this error even without multirec branch.  I believe there is an
> > error in some logic that calculates the correct tuning frequency for a
> > DVB card.  If you go to another transponder and then jump back it
> > usually works.
> >
> > I'd report this as a bug in track, but this is so hard to reproduce
> > without doing a complete database table/channel/devices/videosource
> > dump.
>
> Does this only happen with DVB-S ?

I only have DVB-S, so I can't comment about ATSC (I'm in western Canada).


> I saw this warning when testing my DVB-S card, it didn't seem
> to have any effect for me and it wasn't reproducible, but I've
> never seen this with 8-VSB or QAM tuning.

It usually happens once during initial tuning to that
transport/sourceid.  After you get the error message (and the non-lock
message on the screen) you jump to another transport and then back to
the original one it works as intended.  Most times you need to restart
the backend again to reproduce the problem.  The DVB card in question
(I have two) is setup with a diseqc motor and switch where as my other
DVB card only has a diseqc switch and it has no problems.


> If it is DVB-S only, it probably has something to do with
> the LNB adjustment. It might even be restricted to certain
> LNB's. I have a European style "Universal" LNB.

Not sure I understand it that way.  It's up to myth to select the
correct local tuning frequency given the desired transport frequency
and local oscillator of the LNB.  The error is being reported by a
quick sanity check in the myth code to make sure the local tuning
frequency is within reasonable expected bounds.  Somewhere before that
myth is calculating this frequency incorrectly for certain
source/transport/cardinput situations.

I have two LNBs setup on a disqec motor (circular and Linear LNB on
two ports of a 4-way DiSEqC stitch).

I've tried to dig into the diseqc tree code in myth to see if the
problem was in it loading up the values from the database, but it's
way over my head to understand (I know C but not C++).  I also noticed
that the diseqc tree code tries to reduce the number of steps in
retuning to a transport in order to speed up tuning times.  I wonder
if it's skipping over a step (as it was assuming that step was already
set) when it shouldn't be.  Just a thought.