Mailing List Archive: MythTV: Mythtvnz

Diagnosing recording wrong channel

Index | Next | Previous | View Threaded

worik.stanton at gmail

Jun 19, 2012, 8:05 PM

Post #1 of 14 (657 views)
Permalink

Diagnosing recording wrong channel

I have had a few instances of programmes being recorded from the wrong
channel. The correct time but, obviously, the wrong programme! I need
some help diagnosing the cause.

For example I have CSI programmed to record (using programme finder, one
showing of this title a week).

Looking at log files I see it recorded from channel number 1041

worik [at] mythd:/var/log/mythtv$ zgrep CSI mythbackend.log*|grep
recording|head -n 2
mythbackend.log.1:2012-06-16 20:30:02.709 Started recording: "CSI: Crime
Scene Investigation": channel 1041 on cardid 1, sourceid 1
mythbackend.log.1:2012-06-16 21:36:00.854 Finished recording CSI: Crime
Scene Investigation: channel 1041

The channel number for TV3 is 1003.

Looking at upcoming rules it is clearly marked for TV3.

I do not know what to do now.

BTW:
worik [at] mythd:/var/log/mythtv$ aptitude show mythtv-backend
Package: mythtv-backend
State: installed
Automatically installed: yes
Version: 2:0.24.0+fixes.20110908.1de0431-0ubuntu1

worik [at] mythd:/var/log/mythtv$ uname --all
Linux mythdu 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:58:20 UTC
2012 i686 i686 i386 GNU/Linux

Ubuntu 11.10

cheers
Worik

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

tim.stonehouse at gmail

Jun 19, 2012, 8:24 PM

Post #2 of 14 (640 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 20 June 2012 15:05, Worik Stanton <worik.stanton [at] gmail> wrote:

> I have had a few instances of programmes being recorded from the wrong
> channel. The correct time but, obviously, the wrong programme! I need
> some help diagnosing the cause.
>
> For example I have CSI programmed to record (using programme finder, one
> showing of this title a week).
>
> Looking at log files I see it recorded from channel number 1041
>
> worik [at] mythd:/var/log/mythtv$ zgrep CSI mythbackend.log*|grep
> recording|head -n 2
> mythbackend.log.1:2012-06-16 20:30:02.709 Started recording: "CSI: Crime
> Scene Investigation": channel 1041 on cardid 1, sourceid 1
> mythbackend.log.1:2012-06-16 21:36:00.854 Finished recording CSI: Crime
> Scene Investigation: channel 1041
>
> The channel number for TV3 is 1003.
>
> Looking at upcoming rules it is clearly marked for TV3.
>
> I do not know what to do now.
>
> BTW:
> worik [at] mythd:/var/log/mythtv$ aptitude show mythtv-backend
> Package: mythtv-backend
> State: installed
> Automatically installed: yes
> Version: 2:0.24.0+fixes.20110908.**1de0431-0ubuntu1
>
> worik [at] mythd:/var/log/mythtv$ uname --all
> Linux mythdu 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:58:20 UTC 2012
> i686 i686 i386 GNU/Linux
>
> Ubuntu 11.10
>
> cheers
> Worik
>
>
> --
> it does not matter I think that I shall never see
> how much I dig and dig A billboard lovely as a tree
> this hole just Indeed, unless the billboards fall
> keeps getting deeper I'll never see a tree at all
>
>
> ______________________________**_________________
> mythtvnz mailing list
> mythtvnz [at] lists
> http://lists.ourshack.com/**mailman/listinfo/mythtvnz<http://lists.ourshack.com/mailman/listinfo/mythtvnz>
> Archives http://www.gossamer-threads.**com/lists/mythtv/mythtvnz/<http://www.gossamer-threads.com/lists/mythtv/mythtvnz/>
>

Have you just updated the channel info using a scan due to frequency
changes? I did this and found I have to fix the original channels setting
frequency to the new one.

Tim

worik.stanton at gmail

Jun 19, 2012, 8:45 PM

Post #3 of 14 (641 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 20/06/12 15:24, Tim Stonehouse wrote:
> On 20 June 2012 15:05, Worik Stanton <worik.stanton [at] gmail
> <mailto:worik.stanton [at] gmail>> wrote:
>
> I have had a few instances of programmes being recorded from the
> wrong channel. The correct time but, obviously, the wrong
> programme! I need some help diagnosing the cause.
>
> For example I have CSI programmed to record (using programme
> finder, one showing of this title a week).
>
> Looking at log files I see it recorded from channel number 1041
>
> worik [at] mythd:/var/log/mythtv$ zgrep CSI mythbackend.log*|grep
> recording|head -n 2
> mythbackend.log.1:2012-06-16 20:30:02.709 Started recording: "CSI:
> Crime Scene Investigation": channel 1041 on cardid 1, sourceid 1
> mythbackend.log.1:2012-06-16 21:36:00.854 Finished recording CSI:
> Crime Scene Investigation: channel 1041
>
> The channel number for TV3 is 1003.
>
[snip]
> Have you just updated the channel info using a scan due to frequency
> changes? I did this and found I have to fix the original channels
> setting frequency to the new one.
>

Good idea, but I have done that.

cheers
W

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

stephen_agent at jsw

Jun 20, 2012, 2:31 AM

Post #4 of 14 (632 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On Wed, 20 Jun 2012 15:05:37 +1200, you wrote:

>I have had a few instances of programmes being recorded from the wrong
>channel. The correct time but, obviously, the wrong programme! I need
>some help diagnosing the cause.
>
>For example I have CSI programmed to record (using programme finder, one
>showing of this title a week).
>
>Looking at log files I see it recorded from channel number 1041
>
>worik [at] mythd:/var/log/mythtv$ zgrep CSI mythbackend.log*|grep
>recording|head -n 2
>mythbackend.log.1:2012-06-16 20:30:02.709 Started recording: "CSI: Crime
>Scene Investigation": channel 1041 on cardid 1, sourceid 1
>mythbackend.log.1:2012-06-16 21:36:00.854 Finished recording CSI: Crime
>Scene Investigation: channel 1041
>
>The channel number for TV3 is 1003.
>
>Looking at upcoming rules it is clearly marked for TV3.
>
>I do not know what to do now.
>
>BTW:
>worik [at] mythd:/var/log/mythtv$ aptitude show mythtv-backend
>Package: mythtv-backend
>State: installed
>Automatically installed: yes
>Version: 2:0.24.0+fixes.20110908.1de0431-0ubuntu1
>
>worik [at] mythd:/var/log/mythtv$ uname --all
>Linux mythdu 3.0.0-21-generic #35-Ubuntu SMP Fri May 25 17:58:20 UTC
>2012 i686 i686 i386 GNU/Linux
>
>Ubuntu 11.10
>
>cheers
>Worik

You might like to try this SQL query to see what the tuning data being
used for channel 3 is:

#!/bin/bash
# Lookup the DVB tuning data for a given channel number.
source /etc/mythtv/mysql.txt
mysql -r -t -u $DBUserName -p$DBPassword -h $DBHostName $DBName << EOF

select
channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
from channel,dtv_multiplex where channel.channum=3 and
dtv_multiplex.mplexid=channel.mplexid;
EOF

exit 0

I did it as a full bash script in case you are not familiar with SQL
queries. The "select" statement is all one line - it will be
displayed wrapped in most newsreader software. This script presumes
that TV3 is on channum = 3, as 1003 is clearly a chanid value.

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

worik.stanton at gmail

Jun 20, 2012, 6:04 PM

Post #5 of 14 (633 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 20/06/12 21:31, Stephen Worthington wrote:
> On Wed, 20 Jun 2012 15:05:37 +1200, you wrote:
>
>> I have had a few instances of programmes being recorded from the wrong
>> channel. The correct time but, obviously, the wrong programme! I need
>> some help diagnosing the cause.
>>
[snip]
> You might like to try this SQL query to see what the tuning data being
> used for channel 3 is:
>
> #!/bin/bash
> # Lookup the DVB tuning data for a given channel number.
> source /etc/mythtv/mysql.txt
> mysql -r -t -u $DBUserName -p$DBPassword -h $DBHostName $DBName<< EOF
>
> select
> channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
> from channel,dtv_multiplex where channel.channum=3 and
> dtv_multiplex.mplexid=channel.mplexid;
> EOF

Running....
select
channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
from channel,dtv_multiplex where dtv_multiplex.mplexid=channel.mplexid
order by chanid;

(To get data for all channels)

I attached the output.

Why are all networkid the same?

Transportid seems to map directly to frequency. But channels share
frequencies. Is that OK? Why?

The sourceid is the tuner? I only have one (currently).

What is the mplexid?

cheers
Worik

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

Attachments:

foo.txt (1.88 KB)

dmoo1790 at ihug

Jun 20, 2012, 7:06 PM

Post #6 of 14 (628 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 21/06/12 13:04, Worik Stanton wrote:
> On 20/06/12 21:31, Stephen Worthington wrote:
>> On Wed, 20 Jun 2012 15:05:37 +1200, you wrote:
>>
>>> I have had a few instances of programmes being recorded from the wrong
>>> channel. The correct time but, obviously, the wrong programme! I need
>>> some help diagnosing the cause.
>>>
> [snip]
>> You might like to try this SQL query to see what the tuning data being
>> used for channel 3 is:
>>
>> #!/bin/bash
>> # Lookup the DVB tuning data for a given channel number.
>> source /etc/mythtv/mysql.txt
>> mysql -r -t -u $DBUserName -p$DBPassword -h $DBHostName $DBName<< EOF
>>
>> select
>> channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
>>
>> from channel,dtv_multiplex where channel.channum=3 and
>> dtv_multiplex.mplexid=channel.mplexid;
>> EOF
>
> Running....
> select
> channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
>
> from channel,dtv_multiplex where dtv_multiplex.mplexid=channel.mplexid
> order by chanid;
>
> (To get data for all channels)
>
> I attached the output.
>
> Why are all networkid the same?
>
> Transportid seems to map directly to frequency. But channels share
> frequencies. Is that OK? Why?
>
> The sourceid is the tuner? I only have one (currently).
>
> What is the mplexid?
>
> cheers
> Worik
>

Serviceid is also crucial to selecting a particular program from an mpeg
transport stream. It's stored in the channel table so add serviceid to
the front of the sql query. Could be much grief with wrong or duplicated
serviceids.

Bit odd that networkid is the same for all broadcasters. But my system
is the same so I guess it is irrelevant.

Yes, channels share frequencies because each frequency (or carrier)
carries multiple channels multiplexed into one bit stream. Once myth has
the tuner set to the appropriate frequency it then needs to demux the
appropriate channel (identified by serviceid) to record what you want.

Sourceid is the antenna. So if you have multiple antenna ports (cards)
you would have multiple sourceids. I have a dual tuner card but only one
antenna port and one sourceid.

Not certain but mplexid just seems to be a number linking the channel
table to the dtv_multiplex table. Doubt whether it's actually used for
tuning.

My guess is you need the correct mplexid and serviceid in the channels
table and mplexid should point at the correct dtv_multiplex record for
each channel. Any crossed wires here could lead to myth tuning to the
wrong frequency or demuxing the wrong serviceid.

Have you tried live TV to see what channel you actually get for each
channel number?

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

stephen_agent at jsw

Jun 20, 2012, 8:00 PM

Post #7 of 14 (635 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On Thu, 21 Jun 2012 13:04:36 +1200, you wrote:

>On 20/06/12 21:31, Stephen Worthington wrote:
>> On Wed, 20 Jun 2012 15:05:37 +1200, you wrote:
>>
>>> I have had a few instances of programmes being recorded from the wrong
>>> channel. The correct time but, obviously, the wrong programme! I need
>>> some help diagnosing the cause.
>>>
>[snip]
>> You might like to try this SQL query to see what the tuning data being
>> used for channel 3 is:
>>
>> #!/bin/bash
>> # Lookup the DVB tuning data for a given channel number.
>> source /etc/mythtv/mysql.txt
>> mysql -r -t -u $DBUserName -p$DBPassword -h $DBHostName $DBName<< EOF
>>
>> select
>> channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
>> from channel,dtv_multiplex where channel.channum=3 and
>> dtv_multiplex.mplexid=channel.mplexid;
>> EOF
>
>Running....
>select
>channum,chanid,dtv_multiplex.mplexid,dtv_multiplex.sourceid,transportid,networkid,frequency
>from channel,dtv_multiplex where dtv_multiplex.mplexid=channel.mplexid
>order by chanid;
>
>(To get data for all channels)
>
>I attached the output.
>
>Why are all networkid the same?
>
>Transportid seems to map directly to frequency. But channels share
>frequencies. Is that OK? Why?
>
>The sourceid is the tuner? I only have one (currently).
>
>What is the mplexid?
>
>cheers
>Worik

Here is how it all works, as best as I can tell so far.

Some background first.

DVB-T and DVB-S channels are just streams of digital data packets
marked with ID numbers to say what channel they are and what stream
for that channel (eg video, audio, teletext, EIT). A group of
channels is transmitted on each frequency, what in analogue terms used
to be one channel frequency. The frequency has a designated bandwidth
that determines how much data it can carry. Different streams have
different amounts of data - and HD video stream such as for TV3 takes
much more bandwidth than an SD one as for Prime. So a calculation is
done to see what channels will fit on one frequency. The bundle of
channels and other data streams on one frequency is called a
multiplex.

A DVB-T or DVB-S tuner tunes to a multiplex frequency just like an
analogue tuner. It makes available all the data packets as they
arrive, and to tune for a particular channel or stream on the
multiplex, the tuner has a software or hardware filter that is
programmed for the packet ID numbers that are needed and it just drops
all the other unneeded packets. If more than one channel is to be
recorded from a multiplex, the same tuner can be used by simply
telling it the correct packet IDs to filter out for each channel and
where to send those packets. The ability of software to record
multiple channels from the same multiplex is called "multirec", and is
often not present is cheap PVR boxes.

The following explanation is a little simplified, due to the
complexities of various priority values in the database.

So now mythbackend is starting a recording on channel 3. The records
in the channel table matching channel 3 are looked up. There can be
more than one if the channel is available on DVB-T, DVB-S and Sky, in
which case there will be records with different chanid values but the
same channum. The highest recpriority value record is used, and if a
matching tuner is available it will be selected to be used, otherwise
mythbackend goes back and finds a lower priority tuner to use. Once
it has selected the channel record it is using it keeps a copy of the
chanid value to access that record. It uses the sourceid to work out
what tuners match that record (eg DVB-T, DVB-S, analogue input from
Sky box). Once it has decided that the matching tuners are DVB-T (or
DVB-S), it gets the mplexid value from the channel record and uses
that to look up the one matching dtv_multiplex record. The freqid
value in the channel record is used for tuning analogue channels, and
is ignored for digital channels. The dtv_multiplex record frequency
value is used to tune the DVB-T tuner to the channel, and other values
from the dvt_multiplex record (such as fec, modulation) are used to
set up decoding of the data from the analogue signal. Once the
channel decoding is set up, the tuner will be receiving data packets
and will be able to verify it has the right multiplex using the
transportid and networkid values which are transmitted in the data
packets. I am not entirely sure if the networkid and transportid
values are actually checked or just ignored and what would happen if
there was a mismatch. The networkid values seem to be different
between DVB-T and DVB-S and might also differ between DVB-S
satellites, but I am not sure exactly how they work. The transportid
values identify the multiplex. The difference between an mplexid and
a transportid is that a transportid is a value transmitted in the
packets on a multiplex. An mplexid is just an index into the tables
in the mythconverg database.

Once the tuner is set up and receiving data for the multiplex,
mythbackend then uses the serviceid value from the channel record to
select all the data streams for that channel out of the streams on the
multiplex. The serviceid is transmitted in the data packets
identifying the channel on the multiplex.

So, in the output of the SQL query I got you to do, the mplexid,
frequency and transportid values must all match, which they do. The
networkid values are all the same as all the channels are from DVB-T.
So everything in that output looks fine.

I think we need to see what is in the channel table now. Please
replace the select line in the batch file with:

select channum,chanid,callsign,name,recpriority,mplexid,serviceid from
channel where channum < 100 order by (channum+0);

and see especially if there are multiple entries for any channum.

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

worik.stanton at gmail

Jun 20, 2012, 8:11 PM

Post #8 of 14 (628 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 21/06/12 14:06, David Moore wrote:
> Have you tried live TV to see what channel you actually get for each
> channel number?
I have not noticed any problems with live TV.

This is an intermittent problem with recordings.

cheers
Worik

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

worik.stanton at gmail

Jun 20, 2012, 8:50 PM

Post #9 of 14 (625 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 21/06/12 15:00, Stephen Worthington wrote:
> I think we need to see what is in the channel table now. Please
> replace the select line in the batch file with:
>
> select channum,chanid,callsign,name,recpriority,mplexid,serviceid from
> channel where channum< 100 order by (channum+0);
>
> and see especially if there are multiple entries for any channum.
Interesting. The first 18 lines are different from the next 20. A null
channum so there are multiple entries for channum is NULL.

cheers
Worik

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

Attachments:

ChanTab.txt (3.90 KB)

stevehodge at gmail

Jun 20, 2012, 11:00 PM

Post #10 of 14 (630 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On Thu, Jun 21, 2012 at 3:50 PM, Worik Stanton <worik.stanton [at] gmail>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

stephen_agent at jsw

Jun 21, 2012, 12:37 AM

Post #11 of 14 (621 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

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>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.

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

stevehodge at gmail

Jun 21, 2012, 1:36 AM

Post #12 of 14 (624 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On Thu, Jun 21, 2012 at 7:37 PM, Stephen Worthington <
stephen_agent [at] jsw> wrote:

> 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;
>

Alternatively, if you'd prefer to keep them but not use them:
update channel set visible = 0 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;
>

If you do keep them you'll want to fix up the tuning data (freqid).

Cheers,
Steve

worik.stanton at gmail

Jun 21, 2012, 11:49 PM

Post #13 of 14 (619 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On 21/06/12 19:37, Stephen Worthington wrote:
> delete from channel where chanid> 1035 and chanid<= 1053 and mplexid
> = NULL;
That would be...

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

[snip]
> You will probably need to also increase the number of virtual tuners
> you have set for each DVB-T tuner (see the other thread).
Done.
> 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;
I am running 0.24. It does look like the upgrade 0.24 -> 0.25 is
painful, and unless it fixes this problem there is no reason for it.
I'll see if cleaning up that table stops the problem (happened last
night channel 3 instead of channel two)

describe channel output....
+-------------------+-----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-----------------------+------+-----+---------+-------+
| chanid | int(10) unsigned | NO | PRI | 0 | |
| channum | varchar(10) | NO | MUL | | |
| freqid | varchar(10) | YES | | NULL | |
| sourceid | int(10) unsigned | YES | MUL | NULL | |
| callsign | varchar(20) | NO | | | |
| name | varchar(64) | NO | | | |
| icon | varchar(255) | NO | | none | |
| finetune | int(11) | YES | | NULL | |
| videofilters | varchar(255) | NO | | | |
| xmltvid | varchar(64) | NO | | | |
| recpriority | int(10) | NO | | 0 | |
| contrast | int(11) | YES | | 32768 | |
| brightness | int(11) | YES | | 32768 | |
| colour | int(11) | YES | | 32768 | |
| hue | int(11) | YES | | 32768 | |
| tvformat | varchar(10) | NO | | Default | |
| visible | tinyint(1) | NO | MUL | 1 | |
| outputfilters | varchar(255) | NO | | | |
| useonairguide | tinyint(1) | YES | | 0 | |
| mplexid | smallint(6) | YES | | NULL | |
| serviceid | mediumint(8) unsigned | YES | | NULL | |
| tmoffset | int(11) | NO | | 0 | |
| atsc_major_chan | int(10) unsigned | NO | | 0 | |
| atsc_minor_chan | int(10) unsigned | NO | | 0 | |
| last_record | datetime | NO | | NULL | |
| default_authority | varchar(32) | NO | | | |
| commmethod | int(11) | NO | | -1 | |
+-------------------+-----------------------+------+-----+---------+-------+

--
it does not matter I think that I shall never see
how much I dig and dig A billboard lovely as a tree
this hole just Indeed, unless the billboards fall
keeps getting deeper I'll never see a tree at all

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

stephen_agent at jsw

Jun 22, 2012, 2:37 AM

Post #14 of 14 (613 views)
Permalink

Re: Diagnosing recording wrong channel [In reply to]

On Fri, 22 Jun 2012 18:49:26 +1200, you wrote:

>On 21/06/12 19:37, Stephen Worthington wrote:
>> delete from channel where chanid> 1035 and chanid<= 1053 and mplexid
[snip]
>> 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;
>I am running 0.24. It does look like the upgrade 0.24 -> 0.25 is
>painful, and unless it fixes this problem there is no reason for it.
>I'll see if cleaning up that table stops the problem (happened last
>night channel 3 instead of channel two)

Here is the SQL to add the radio channels:

INSERT INTO `channel` VALUES
(1050,'50','36',1,'RNZ National','Radio NZ
National','/home/stephen/.mythtv/channels/radio_nz_national.jpg',0,'','rnz-national.freeviewnz.tv',0,32768,32768,32768,32768,'Default',1,'',1,6,2000,0,0,0,'2011-11-26
22:27:40','crid://radionznational.co.nz',-1),
(1051,'51','36',1,'RNZ Concert','Radio NZ
Concert','/home/stephen/.mythtv/channels/radio_nz_concert.jpg',0,'','rnz-concert.freeviewnz.tv',0,32768,32768,32768,32768,'Default',1,'',1,6,2001,0,0,0,'0000-00-00
00:00:00','crid://radionzconcert.co.nz',-1),
(1071,'71','36',1,'BaseFM','BaseFM','/home/stephen/.mythtv/channels/basefm.jpg',0,'','base-fm.freeviewnz.tv',0,32768,32768,32768,32768,'Default',1,'',1,6,2002,0,0,0,'0000-00-00
00:00:00','crid://basefm.co.nz',-1),
;

You will need to adjust the "icon" field values (the
"/home/stephen/.mythtv/channels/" bits) to point to wherever you are
storing your channel icon files. The '36' in the "freqid" (third from
the left) may also not be correct for your transmitter. It is
actually unused, but probably should match the dtv_multiplex.frequency
value just in case. So do this query:

select channum,chanid,freqid,name,icon from channel where channum =
10;

That should give you the freqid for Prime, which is on the same
(Kordia) multiplex as the radio channels. Use that value instead of
'36', and see what the correct icon path is.

_______________________________________________
mythtvnz mailing list
mythtvnz [at] lists
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads