Mailing List Archive

On Fri, 11 Mar 2022 19:53:21 +1300, you wrote:

>https://freeviewnz.tv/ch-changes/[1]
>
>Also some are moving to different channels.

It looks like the new channel scanning code can cope with this sort of
thing now. I fired up an old v31 on my test machine, upgraded it to
v32 and added a new Sat>IP DVB-T tuner. When I scanned using the new
tuner, it found all the changes that have happened over the last few
years since its last DVB-T scan and updated the existing channels
nicely. The only anomaly I found was it created a new Te Reo channel
instead of updating the existing one - I can not see any reason for
that. All the channels that no longer exist got an underscore added
to their channel number (channum), and changed names and callsigns for
the TVNZ channels were all updated correctly. Breeze TV and TVNZ
DUKE+1 got added. The record.station fields were not changed that I
could see, but I am not sure if that matters as I think they are not
used now.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

I am ready to scan tomorrow (21st March) thanks to advice from Stephen.

Connecting a monitor to my backend allows me to run mythtv-setup (it
cannot run via a vnc session without setting up a dummy monitor)

Also, after the upgrade to v32 my PC frontend would not run. It turned
out to be a need to upgrade my nVidia video card (the old one is no
longer supported on newer kernels).

Rob

On 11/03/22 21:45, Stephen Worthington wrote:
> https://freeviewnz.tv/ch-changes/[1]
>> Also some are moving to different channels.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On 20/03/22 09:54, Robert Fisher wrote:
> I am ready to scan tomorrow (21st March) thanks to advice from Stephen.
>
> Connecting a monitor to my backend allows me to run mythtv-setup (it
> cannot run via a vnc session without setting up a dummy monitor)
>
> Also, after the upgrade to v32 my PC frontend would not run. It turned
> out to be a need to upgrade my nVidia video card (the old one is no
> longer supported on newer kernels).
>
> Rob
>
> On 11/03/22 21:45, Stephen Worthington wrote:
>> https://freeviewnz.tv/ch-changes/[1]
>>> Also some are moving to different channels.
>
> I will be also.

I have never been sure whether you do just one channel scan or do you
need to one for each tuner?

Can anyone enlighten me?

-Paul


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sun, 20 Mar 2022 10:06:29 +1300, you wrote:

>
>On 20/03/22 09:54, Robert Fisher wrote:
>> I am ready to scan tomorrow (21st March) thanks to advice from Stephen.
>>
>> Connecting a monitor to my backend allows me to run mythtv-setup (it
>> cannot run via a vnc session without setting up a dummy monitor)
>>
>> Also, after the upgrade to v32 my PC frontend would not run. It turned
>> out to be a need to upgrade my nVidia video card (the old one is no
>> longer supported on newer kernels).
>>
>> Rob
>>
>> On 11/03/22 21:45, Stephen Worthington wrote:
>>> https://freeviewnz.tv/ch-changes/[1]
>>>> Also some are moving to different channels.
>>
>> I will be also.
>
>I have never been sure whether you do just one channel scan or do you
>need to one for each tuner?
>
>Can anyone enlighten me?
>
>-Paul

There are good instructions on channel scanning here:

https://www.mythtv.org/wiki/Channel_Scanning

Make sure you turn on the "Full search for old channels" option. Then
do "Scan of all existing transports". That will scan all 5 of the
multiplexes on their existing frequencies. If you do not have 5
multiplexes at present, or if a new one is ever added or the
frequencies ever get changed, then you need to use "Full scan" so that
all valid frequencies will be scanned to see if a multiplex is
transmitting on them. A full scan takes a long time as there are
many, many unused frequencies to check to find the 5 that are actually
in use.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sun, 20 Mar 2022 15:59:16 +1300, you wrote:

>There are good instructions on channel scanning here:
>
>https://www.mythtv.org/wiki/Channel_Scanning
>
>Make sure you turn on the "Full search for old channels" option. Then
>do "Scan of all existing transports". That will scan all 5 of the
>multiplexes on their existing frequencies. If you do not have 5
>multiplexes at present, or if a new one is ever added or the
>frequencies ever get changed, then you need to use "Full scan" so that
>all valid frequencies will be scanned to see if a multiplex is
>transmitting on them. A full scan takes a long time as there are
>many, many unused frequencies to check to find the 5 that are actually
>in use.

Also, you will need to get EPG for the new channels. So after the
channel scan you will need to edit them and add an xmltvid that
matches your EPG source. I get my FreeviewHD EPG using mhegepgsnoop,
so to make that work, I need to have the xmltvid value that will fuzzy
match to the channel name that is broadcast by Freeview. Until we can
see those names (at 06:00 on Mon 2022-03-21), we do not know for sure
what will match, but it is pretty easy to guess that these will work:

eden.freeviewnz.tv
rush.freeviewnz.tv

Since Choice TV is disappearing, anything that you record from there
that has a recording rule that is set to "This channel" will need to
be fixed to record from Eden instead. In my database, this SQL finds
all such rules:

select recordid,type,chanid,starttime,title,station,filter from record
where filter & 1024 = 1024 and station='ChoiceTV';

As I understand it (and I could be wrong), the "This channel" option
sets a bit in the record.filter field that the mask 1024 (hex 400)
matches. When that bit is on, the recording rule uses the
record.station field to find the matching chanid values from the
channel table callsign field and records only when the EPG data
program.chanid field matches one of those chanid values. So, assuming
that the channel.callsign for Eden turns out to be "Eden", then this
SQL should change all the Choice TV "This channel" rules to now record
from Eden:

update record set station='Eden' where filter & 1024 = 1024 and
station='ChoiceTV';

However, when the Choice TV channel gets deleted, it is possible that
all those Choice TV only rules may be deleted, so I will be making a
copy of my record table before doing the new channel scan so that I
can put all those rules back again afterwards if that happens, and
then I will be able to modify them as above. The easy way to keep a
copy of your old record table is this SQL:

create table record_old like record;
insert into record_old select * from record;

Then after the channel scan, if those rules have been deleted, they
can be added back by this:

insert into record select * from record old where filter & 1024 = 1024
and station='ChoiceTV';

and then the above update SQL can be done to them. When you are
finished with the record_old table, it can be deleted with this:

drop table record_old;

WARNING: If you want to do this sort of SQL updating of your database,
you MUST do a database backup first, so that you can restore it if
anything goes wrong.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sun, 20 Mar 2022 19:18:20 +1300, you wrote:

>>Also, you will need to get EPG for the new channels. So after the
>channel scan you will need to edit them and add an xmltvid that
>matches your EPG source. I get my FreeviewHD EPG using mhegepgsnoop,
>so to make that work, I need to have the xmltvid value that will fuzzy
>match to the channel name that is broadcast by Freeview. Until we can
>see those names (at 06:00 on Mon 2022-03-21), we do not know for sure
>what will match, but it is pretty easy to guess that these will work:
>
>eden.freeviewnz.tv
>rush.freeviewnz.tv
>
>Since Choice TV is disappearing, anything that you record from there
>that has a recording rule that is set to "This channel" will need to
>be fixed to record from Eden instead. In my database, this SQL finds
>all such rules:
>
>select recordid,type,chanid,starttime,title,station,filter from record
>where filter & 1024 = 1024 and station='ChoiceTV';
>
>As I understand it (and I could be wrong), the "This channel" option
>sets a bit in the record.filter field that the mask 1024 (hex 400)
>matches. When that bit is on, the recording rule uses the
>record.station field to find the matching chanid values from the
>channel table callsign field and records only when the EPG data
>program.chanid field matches one of those chanid values. So, assuming
>that the channel.callsign for Eden turns out to be "Eden", then this
>SQL should change all the Choice TV "This channel" rules to now record
>from Eden:
>
>update record set station='Eden' where filter & 1024 = 1024 and
>station='ChoiceTV';
>
>However, when the Choice TV channel gets deleted, it is possible that
>all those Choice TV only rules may be deleted, so I will be making a
>copy of my record table before doing the new channel scan so that I
>can put all those rules back again afterwards if that happens, and
>then I will be able to modify them as above. The easy way to keep a
>copy of your old record table is this SQL:
>
>create table record_old like record;
>insert into record_old select * from record;
>
>Then after the channel scan, if those rules have been deleted, they
>can be added back by this:
>
>insert into record select * from record old where filter & 1024 = 1024
>and station='ChoiceTV';
>
>and then the above update SQL can be done to them. When you are
>finished with the record_old table, it can be deleted with this:
>
>drop table record_old;
>
>WARNING: If you want to do this sort of SQL updating of your database,
>you MUST do a database backup first, so that you can restore it if
>anything goes wrong.

And on further consideration, I think it would be best to also update
the chanid on the Choice TV rules that are being updated so that it is
the chanid for the new Eden channel. Which will not be known until
after the channel scan creates the Eden channel. To find Eden's
chanid, this should work:

select
chanid,channum,freqid,sourceid,callsign,name,xmltvid,mplexid,serviceid
from channel where name like '%eden%';

And then the update becomes:

update record set chanid=<new Eden chanid>, station='Eden' where
filter & 1024 = 1024 and station='ChoiceTV';

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

I seem to recollect that some of these can be added/edited in
/mythweb/settings/tv/channels

On 20/03/22 20:49, Stephen Worthington wrote:
>> Also, you will need to get EPG for the new channels. So after the
> channel scan you will need to edit them and add an xmltvid that
> matches your EPG source.

On Sun, 20 Mar 2022 20:49:14 +1300, you wrote:

>On Sun, 20 Mar 2022 19:18:20 +1300, you wrote:
>
>>>Also, you will need to get EPG for the new channels. So after the
>>channel scan you will need to edit them and add an xmltvid that
>>matches your EPG source. I get my FreeviewHD EPG using mhegepgsnoop,
>>so to make that work, I need to have the xmltvid value that will fuzzy
>>match to the channel name that is broadcast by Freeview. Until we can
>>see those names (at 06:00 on Mon 2022-03-21), we do not know for sure
>>what will match, but it is pretty easy to guess that these will work:
>>
>>eden.freeviewnz.tv
>>rush.freeviewnz.tv
>>
>>Since Choice TV is disappearing, anything that you record from there
>>that has a recording rule that is set to "This channel" will need to
>>be fixed to record from Eden instead. In my database, this SQL finds
>>all such rules:
>>
>>select recordid,type,chanid,starttime,title,station,filter from record
>>where filter & 1024 = 1024 and station='ChoiceTV';
>>
>>As I understand it (and I could be wrong), the "This channel" option
>>sets a bit in the record.filter field that the mask 1024 (hex 400)
>>matches. When that bit is on, the recording rule uses the
>>record.station field to find the matching chanid values from the
>>channel table callsign field and records only when the EPG data
>>program.chanid field matches one of those chanid values. So, assuming
>>that the channel.callsign for Eden turns out to be "Eden", then this
>>SQL should change all the Choice TV "This channel" rules to now record
>>from Eden:
>>
>>update record set station='Eden' where filter & 1024 = 1024 and
>>station='ChoiceTV';
>>
>>However, when the Choice TV channel gets deleted, it is possible that
>>all those Choice TV only rules may be deleted, so I will be making a
>>copy of my record table before doing the new channel scan so that I
>>can put all those rules back again afterwards if that happens, and
>>then I will be able to modify them as above. The easy way to keep a
>>copy of your old record table is this SQL:
>>
>>create table record_old like record;
>>insert into record_old select * from record;
>>
>>Then after the channel scan, if those rules have been deleted, they
>>can be added back by this:
>>
>>insert into record select * from record old where filter & 1024 = 1024
>>and station='ChoiceTV';
>>
>>and then the above update SQL can be done to them. When you are
>>finished with the record_old table, it can be deleted with this:
>>
>>drop table record_old;
>>
>>WARNING: If you want to do this sort of SQL updating of your database,
>>you MUST do a database backup first, so that you can restore it if
>>anything goes wrong.
>
>And on further consideration, I think it would be best to also update
>the chanid on the Choice TV rules that are being updated so that it is
>the chanid for the new Eden channel. Which will not be known until
>after the channel scan creates the Eden channel. To find Eden's
>chanid, this should work:
>
>select
>chanid,channum,freqid,sourceid,callsign,name,xmltvid,mplexid,serviceid
>from channel where name like '%eden%';
>
>And then the update becomes:
>
>update record set chanid=<new Eden chanid>, station='Eden' where
>filter & 1024 = 1024 and station='ChoiceTV';

The channel updates happened sometime around 05:00 - but for a while
before then, the engineers had screwed up and put a second copy of all
the TVNZ channels on the Kordia 1 mux! Fortunately, they noticed and
fixed that.

The only surprise I found was that the Eden channels were named "eden"
and "eden+1" (lower case first letter). When I scanned though, the
logical channel numbers where not updated for some reason, so I had to
manually change them. That was a pain.

The recording rules for ChoiceTV were not automatically deleted when
the channel was deleted. I eventually decided to change all the
ChoiceTV recording rules to the new eden settings, not just the ones
that were set to "This channel". So the command was:

update record set chanid=<new Eden chanid>, station='eden' where
station='ChoiceTV';

That seems to have worked properly - I can see a couple of old
ChoiceTV programmes scheduled to record from eden.

I also went through all the channels and updated the xmltvid values so
that they matched the channel names, so mhegepgsnoop would fuzzy match
them correctly. That then required that I update the
$(HOME)/.mythtv/FreeviewHD.xmltv file (replace "FreeviewHD" with
whatever you call your FreeviewHD source as). That was able to be
done using a mysql command:

cd ~/.mythtv
sudo mysql mythconverg -e "select concat('channel=',xmltvid) from
channel where sourceid=1 and deleted is null order by xmltvid;" -B -N
>FreeviewHD.xmltv

The sudo mysql command is all on one line (my email client wraps long
lines). You will need to use your sourceid value and the correct name
of your .xmltv file.

Then I ran my EPG gathering script and the new channels all got EPG
data.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

To answer Paul's question, this is from the Wiki page Stephen suggested:-

Remember that the Video Sources and the Input Connections are just software abstractions that enable a single list of channels to be shared among multiple tuners.

?Robert Fisher?

On 21 Mar 2022, 7:41 AM, at 7:41 AM, Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>On Sun, 20 Mar 2022 20:49:14 +1300, you wrote:
>
>>On Sun, 20 Mar 2022 19:18:20 +1300, you wrote:
>>
>>>>Also, you will need to get EPG for the new channels. So after the
>>>channel scan you will need to edit them and add an xmltvid that
>>>matches your EPG source. I get my FreeviewHD EPG using mhegepgsnoop,
>>>so to make that work, I need to have the xmltvid value that will
>fuzzy
>>>match to the channel name that is broadcast by Freeview. Until we
>can
>>>see those names (at 06:00 on Mon 2022-03-21), we do not know for sure
>>>what will match, but it is pretty easy to guess that these will work:
>>>
>>>eden.freeviewnz.tv
>>>rush.freeviewnz.tv
>>>
>>>Since Choice TV is disappearing, anything that you record from there
>>>that has a recording rule that is set to "This channel" will need to
>>>be fixed to record from Eden instead. In my database, this SQL finds
>>>all such rules:
>>>
>>>select recordid,type,chanid,starttime,title,station,filter from
>record
>>>where filter & 1024 = 1024 and station='ChoiceTV';
>>>
>>>As I understand it (and I could be wrong), the "This channel" option
>>>sets a bit in the record.filter field that the mask 1024 (hex 400)
>>>matches. When that bit is on, the recording rule uses the
>>>record.station field to find the matching chanid values from the
>>>channel table callsign field and records only when the EPG data
>>>program.chanid field matches one of those chanid values. So,
>assuming
>>>that the channel.callsign for Eden turns out to be "Eden", then this
>>>SQL should change all the Choice TV "This channel" rules to now
>record
>>>from Eden:
>>>
>>>update record set station='Eden' where filter & 1024 = 1024 and
>>>station='ChoiceTV';
>>>
>>>However, when the Choice TV channel gets deleted, it is possible that
>>>all those Choice TV only rules may be deleted, so I will be making a
>>>copy of my record table before doing the new channel scan so that I
>>>can put all those rules back again afterwards if that happens, and
>>>then I will be able to modify them as above. The easy way to keep a
>>>copy of your old record table is this SQL:
>>>
>>>create table record_old like record;
>>>insert into record_old select * from record;
>>>
>>>Then after the channel scan, if those rules have been deleted, they
>>>can be added back by this:
>>>
>>>insert into record select * from record old where filter & 1024 =
>1024
>>>and station='ChoiceTV';
>>>
>>>and then the above update SQL can be done to them. When you are
>>>finished with the record_old table, it can be deleted with this:
>>>
>>>drop table record_old;
>>>
>>>WARNING: If you want to do this sort of SQL updating of your
>database,
>>>you MUST do a database backup first, so that you can restore it if
>>>anything goes wrong.
>>
>>And on further consideration, I think it would be best to also update
>>the chanid on the Choice TV rules that are being updated so that it is
>>the chanid for the new Eden channel. Which will not be known until
>>after the channel scan creates the Eden channel. To find Eden's
>>chanid, this should work:
>>
>>select
>>chanid,channum,freqid,sourceid,callsign,name,xmltvid,mplexid,serviceid
>>from channel where name like '%eden%';
>>
>>And then the update becomes:
>>
>>update record set chanid=<new Eden chanid>, station='Eden' where
>>filter & 1024 = 1024 and station='ChoiceTV';
>
>The channel updates happened sometime around 05:00 - but for a while
>before then, the engineers had screwed up and put a second copy of all
>the TVNZ channels on the Kordia 1 mux! Fortunately, they noticed and
>fixed that.
>
>The only surprise I found was that the Eden channels were named "eden"
>and "eden+1" (lower case first letter). When I scanned though, the
>logical channel numbers where not updated for some reason, so I had to
>manually change them. That was a pain.
>
>The recording rules for ChoiceTV were not automatically deleted when
>the channel was deleted. I eventually decided to change all the
>ChoiceTV recording rules to the new eden settings, not just the ones
>that were set to "This channel". So the command was:
>
>update record set chanid=<new Eden chanid>, station='eden' where
>station='ChoiceTV';
>
>That seems to have worked properly - I can see a couple of old
>ChoiceTV programmes scheduled to record from eden.
>
>I also went through all the channels and updated the xmltvid values so
>that they matched the channel names, so mhegepgsnoop would fuzzy match
>them correctly. That then required that I update the
>$(HOME)/.mythtv/FreeviewHD.xmltv file (replace "FreeviewHD" with
>whatever you call your FreeviewHD source as). That was able to be
>done using a mysql command:
>
>cd ~/.mythtv
>sudo mysql mythconverg -e "select concat('channel=',xmltvid) from
>channel where sourceid=1 and deleted is null order by xmltvid;" -B -N
>>FreeviewHD.xmltv
>
>The sudo mysql command is all on one line (my email client wraps long
>lines). You will need to use your sourceid value and the correct name
>of your .xmltv file.
>
>Then I ran my EPG gathering script and the new channels all got EPG
>data.
>
>_______________________________________________
>mythtvnz mailing list
>mythtvnz@lists.ourshack.com
>https://lists.ourshack.com/mailman/listinfo/mythtvnz
>Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Is anyone (other than me) using the "Over the air" (EIT) grabber

I have been using it successfully for a few years but after a new
channel scan today I have not got data for all channels.

I did try rerunning mythfilldatabase after a while and got a bit more.

Should I just be more patient?


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Mon, 21 Mar 2022 07:40:27 +1300, you wrote:

>On Sun, 20 Mar 2022 20:49:14 +1300, you wrote:
>
>>On Sun, 20 Mar 2022 19:18:20 +1300, you wrote:
>>
>>>>Also, you will need to get EPG for the new channels. So after the
>>>channel scan you will need to edit them and add an xmltvid that
>>>matches your EPG source. I get my FreeviewHD EPG using mhegepgsnoop,
>>>so to make that work, I need to have the xmltvid value that will fuzzy
>>>match to the channel name that is broadcast by Freeview. Until we can
>>>see those names (at 06:00 on Mon 2022-03-21), we do not know for sure
>>>what will match, but it is pretty easy to guess that these will work:
>>>
>>>eden.freeviewnz.tv
>>>rush.freeviewnz.tv
>>>
>>>Since Choice TV is disappearing, anything that you record from there
>>>that has a recording rule that is set to "This channel" will need to
>>>be fixed to record from Eden instead. In my database, this SQL finds
>>>all such rules:
>>>
>>>select recordid,type,chanid,starttime,title,station,filter from record
>>>where filter & 1024 = 1024 and station='ChoiceTV';
>>>
>>>As I understand it (and I could be wrong), the "This channel" option
>>>sets a bit in the record.filter field that the mask 1024 (hex 400)
>>>matches. When that bit is on, the recording rule uses the
>>>record.station field to find the matching chanid values from the
>>>channel table callsign field and records only when the EPG data
>>>program.chanid field matches one of those chanid values. So, assuming
>>>that the channel.callsign for Eden turns out to be "Eden", then this
>>>SQL should change all the Choice TV "This channel" rules to now record
>>>from Eden:
>>>
>>>update record set station='Eden' where filter & 1024 = 1024 and
>>>station='ChoiceTV';
>>>
>>>However, when the Choice TV channel gets deleted, it is possible that
>>>all those Choice TV only rules may be deleted, so I will be making a
>>>copy of my record table before doing the new channel scan so that I
>>>can put all those rules back again afterwards if that happens, and
>>>then I will be able to modify them as above. The easy way to keep a
>>>copy of your old record table is this SQL:
>>>
>>>create table record_old like record;
>>>insert into record_old select * from record;
>>>
>>>Then after the channel scan, if those rules have been deleted, they
>>>can be added back by this:
>>>
>>>insert into record select * from record old where filter & 1024 = 1024
>>>and station='ChoiceTV';
>>>
>>>and then the above update SQL can be done to them. When you are
>>>finished with the record_old table, it can be deleted with this:
>>>
>>>drop table record_old;
>>>
>>>WARNING: If you want to do this sort of SQL updating of your database,
>>>you MUST do a database backup first, so that you can restore it if
>>>anything goes wrong.
>>
>>And on further consideration, I think it would be best to also update
>>the chanid on the Choice TV rules that are being updated so that it is
>>the chanid for the new Eden channel. Which will not be known until
>>after the channel scan creates the Eden channel. To find Eden's
>>chanid, this should work:
>>
>>select
>>chanid,channum,freqid,sourceid,callsign,name,xmltvid,mplexid,serviceid
>>from channel where name like '%eden%';
>>
>>And then the update becomes:
>>
>>update record set chanid=<new Eden chanid>, station='Eden' where
>>filter & 1024 = 1024 and station='ChoiceTV';
>
>The channel updates happened sometime around 05:00 - but for a while
>before then, the engineers had screwed up and put a second copy of all
>the TVNZ channels on the Kordia 1 mux! Fortunately, they noticed and
>fixed that.
>
>The only surprise I found was that the Eden channels were named "eden"
>and "eden+1" (lower case first letter). When I scanned though, the
>logical channel numbers where not updated for some reason, so I had to
>manually change them. That was a pain.
>
>The recording rules for ChoiceTV were not automatically deleted when
>the channel was deleted. I eventually decided to change all the
>ChoiceTV recording rules to the new eden settings, not just the ones
>that were set to "This channel". So the command was:
>
>update record set chanid=<new Eden chanid>, station='eden' where
>station='ChoiceTV';
>
>That seems to have worked properly - I can see a couple of old
>ChoiceTV programmes scheduled to record from eden.
>
>I also went through all the channels and updated the xmltvid values so
>that they matched the channel names, so mhegepgsnoop would fuzzy match
>them correctly. That then required that I update the
>$(HOME)/.mythtv/FreeviewHD.xmltv file (replace "FreeviewHD" with
>whatever you call your FreeviewHD source as). That was able to be
>done using a mysql command:
>
>cd ~/.mythtv
>sudo mysql mythconverg -e "select concat('channel=',xmltvid) from
>channel where sourceid=1 and deleted is null order by xmltvid;" -B -N
>>FreeviewHD.xmltv
>
>The sudo mysql command is all on one line (my email client wraps long
>lines). You will need to use your sourceid value and the correct name
>of your .xmltv file.
>
>Then I ran my EPG gathering script and the new channels all got EPG
>data.

It looks like channel scans that change the channel.callsign value do
not fix up the recording rules that still use the old callsigns. I
found out the hard way by not having anything record today from the
channels that had changed callsigns (eg TV ONE to TVNZ 1). So I had
to do some SQL to fix that. The following select will show any
recording rules where the callsign in the rule (record.station) does
not match the current callsign in the channel table for that chanid.
It also gives the "new_callsign" that should be being used for the
rule to work.

select recordid,type,chanid,starttime,title,station,filter,(select
callsign from channel c where r.chanid=c.chanid) as new_callsign from
record r where r.station!='' and (select callsign from channel c where
c.chanid=r.chanid)!= r.station order by r.station;

If you want to do the same fix I did, first check the output of the
above for any anomalies - I found some recording rules where the
chanid was for the Sky channel PRIME HD but the station was the
FreeviewHD channel PRIME - so I changed their chanid to the one for
PRIME so they would record from FreeviewHD instead of Sky. Once you
have fixed any anomalies, then run this update to change the
record.station values to match the current channel table callsigns:

update record r set station=(select callsign from channel c where
r.chanid=c.chanid) where r.station!='' and (select callsign from
channel c where c.chanid=r.chanid)!= r.station order by r.station;

Ideally, the MythTV channel scan code should be doing fixups like this
automatically, and also deleting recording rules that use only deleted
channels.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/