[mythtv-users] HDHR Prime Channel Tuning Failure

[Kirk Bocek]

On 10/3/2014 8:37 PM, Gary Buhrmaster wrote:
> On Sat, Oct 4, 2014 at 1:01 AM, Kirk Bocek <t004 at kbocek.com> wrote:
> ....
>> Sigh. I've works so hard to avoid doing this. I have a perl script to
>> manually insert channels.
> As Adam would say: "Well, there's your problem".
>
> <disclaimer>
> The rule is, "you modify the database, you own it"
> (the "if you break it, you own it" sign in the local shop).
> For better or worse, all the business logic and database
> integrity is implemented in the code, and not using any
> sql based referential validation.  Direct insertion of
> data into the database may eventually cause problems
> that can be resolved only by carefully reading,
> understanding, and then reproducing all that logic
> in your direct modifications (and reviewing each and
> every commit to insure it does not impact your direct
> manipulation).
> </disclaimer>
>
> <recommendation>
> If you want to do it the right way, delete your video
> sources.  It is the only way to be sure and maximize
> the likelihood that your future DB upgrades will actually
> work (the schema update process is not assured to
> work with broken databases).
> </recommendation>
>
> <willing_to_accept_possibly_brokenDB>
> Or, for a minimal action, use the channel editor
> to delete channel 731, and then add it back,
> insuring all the values are what you want.  This
> will not fix any other challenged channels, of
> course.
>
> That said, here are some things to look at in the
> channel editor (or the mysql cli).  I would expect
> that if you look at a channel that works, and this
> one (which does not) it should be obvious what
> is broken in the channel table (although I think
> the channel editor does not display both the
> channum and the freqid, so you may be forced
> to use the mysql cli).
>
>> Since this is a HDHR Prime, mplexid and serviceid shouldn't
>> matter.
> Used to be the case that mplexid of 32767 was "special"
> and was required in some cases (something to do with
> old lineups I think).  If your existing channels all have a
> value, and it is the same, use that (I think NULL is the
> current default, but I do not know if that changed over
> the years).
>
>> Anyone know any other settings that might screw up
>> channel tuning on a prime?
> The channum is what is displayed, and the freqid is used
> to tune (I think that is right, maybe it is reversed, but
> for a Prime, both are typically the same anyway).  Make
> sure they are what you expect.
>
> Make sure you do not (somehow) have two channels
> with the same channum.
>
> </willing_to_accept_possibly_brokenDB>
>
> Perhaps others will have better ideas.
> _______________________________________________
>
Solved.

I wrote a script some time ago to help with classic HDHRs (it's still on 
the wiki) and was warned because my script was doing direct database 
manipulations. I get it and accept the disapprobation of my peers.

On the other hand, the perl bindings are poorly documented and really 
hard to figure out. End whine.

Short answer, replace mplexid in the broken channels with 32767 and they 
work again.

Long answer, I *was* using 0 in this script for mplexid for a long time. 
But it stopped working and rather than fix the script as I should have, 
I started using 1 for mplexid. This was the error. I *assumed* that 
mplexid did not matter due to the whole vchannel thing in the HDHR 
Prime. I thought it or Myth would extract the proper mplexid. Well I 
guess it still is but if mplexid=1 it looks like it tries to set that 
value which is wrong.

I checked some of the other channels I had added in the recent months 
and they had tuning problems too. Virtually all were trash channel I 
would never use so I never caught this problem.

Looks like 32767 *is* a special value. It fixes my problem.

Thanks for the help Gary.