[mythtvnz] New channels happening from March 21st

Robert Fisher robert at fisher.net.nz
Sun Mar 20 21:10:56 GMT 2022


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 at 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 at lists.ourshack.com
>https://lists.ourshack.com/mailman/listinfo/mythtvnz
>Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/mythtvnz/attachments/20220321/9c5b68dc/attachment.html>


More information about the mythtvnz mailing list