[mythtvnz] Diagnosing recording wrong channel

[Stephen Worthington]

On Thu, 21 Jun 2012 18:00:51 +1200, you wrote:

>On Thu, Jun 21, 2012 at 3:50 PM, Worik Stanton <worik.stanton at gmail.com>wrote:
>
>> select channum,chanid,callsign,name,recpriority,mplexid,serviceid from
>> channel where channum<  100 order by (channum+0);
>
>
>Really would have been better to include sourceid in that query. And
>probably don't need the where clause either:
>select sourceid, channum, chanid, callsign, recpriority, mplexid,
>serviceid, freqid from channel order by callsign;
>
>>
>Looking at log files I see it recorded from channel number 1041
>>
>
>+---------+--------+------------------+------------------+-------------+---------+-----------+
>| channum | chanid | callsign         | name             | recpriority
>| mplexid | serviceid |
>+---------+--------+------------------+------------------+-------------+---------+-----------+
>|         |   1041 | TV3              | TV 3             |           0
>|    NULL |         0 |
>
>| 3       |   1003 | TV3              | TV3              |           0
>|       4 |      1300 |
>+---------+--------+------------------+------------------+-------------+---------+-----------+
>
>
>Notice that 1041 and 1003 are both TV3. Do you have an analogue recorder?
>It looks like 1041 is an analogue channel. It probably has incorrect tuning
>data. Probably what is happening is that the scheduler is assigning
>something else to record on the DVB tuner and assigning CSI or whatever to
>record on 1041. This can happen because the two channels have the same
>callsign and matching guide data. But 1041 isn't actually TV3 - the tuning
>data is wrong.
>
>FYI, channum is really only used to select a channel using the number keys
>in the frontend. It's perfectly ok for it to be null. Callsign is what the
>scheduler uses to identify a channel (as in a stream of video with a
>program schedule). Chanid specifies a particular channel on a particular
>source.
>
>If you are using those channels with null channel number then fix up the
>tuning data. If you are not using them then either delete them or set the
>"visible" column to false for those rows.
>
>Cheers,
>Steve

Yes, that does appear to be the heart of your problem.  I had
forgotten that the callsign field is what is used to look up the
channel table for recordings.  It is a bad idea to have channel table
rows with the same callsign, unless they have different recpriority
values (eg high priority for DVB-T, lower priority for the same
channel on DVB-S).

The channum field is a character field, so the values are '' (empty
string), not NULL, which is a different value.  In SQL, it is
important to make that distinction, otherwise you can wind up deleting
or changing the wrong thing.

So if all those rows with mplexid = NULL are not valid analogue
channels, this command should delete them:

delete from channel where chanid > 1035 and chanid <= 1053 and mplexid
= NULL;

If they are valid analogue channels, then this should give them lower
priority than the DVB-T channels:

update channel set recpriority = -1 where chanid > 1035 and chanid <=
1053 and mplexid = NULL;

You will probably need to also increase the number of virtual tuners
you have set for each DVB-T tuner (see the other thread).

However, that will still leave you without any of the radio channels -
they do not seem to have turned up in your initial tuning scan.  So
you will need to add them in.  I could provide a script to do that,
but I am still running Mythtv 0.24-fixes, and I am not sure if there
were any changes to the channel table for 0.25, which I presume you
are using.  So please run this SQL command:

describe channel;

and post the results so I can make sure the script will work properly.