[mythtvnz] New channels happening from March 21st

[Stephen Worthington]

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.