[mythtv-users] Can't seem to delete channels

[Stephen Worthington]

On Thu, 29 Jul 2021 13:02:12 -0400, you wrote:

>    > Date: Thu, 29 Jul 2021 08:37:47 +0100
>    > From: David Watkins <watkinshome at gmail.com>
>
>    > Since relatively recently MythTV will hang on to deleted channels as long
>    > as long as there are any recordings made from them.
>
>    > They should be marked as 'deleted' in the database.
>
>    > In my experience MythWeb has not been updated to work with this continues
>    > to display them and shows strange behaviour if the same channel appears on
>    > a different source.
>
>I don't think this is a mythweb problem.  In the frontend right now, I'm
>seeing it trying and failing to record two programs simultaneously from
>the SD and HD source of a channel I don't get, which I set disabled last
>night.  And I see upcoming recordings trying to record simultaneously
>from the SD and HD versions of several other channels to which I do
>subscribe, yet I disabled all SD channels which had HD equivalents.
>
>I don't have any other sources.  I'm also surprised that my supposedly-
>deleted channels appear to still be getting data fetched for them; I was
>assuming that the grabber wouldn't bother to fetch, store in sqlite, or
>give to the backend to store in mysql, channels that the user wasn't
>going to use.
>
>When I imported my old DB, Myth assigned all my old (standard-def, from
>cable boxes) channels to source 1, even though they were source 3 on the
>old system.  (Source 1 and source 2 on the old system haven't been
>available in years because I'd switched cable providers, etc.)  Before
>my first run of mfdb under v31, I used the Channel Editor to delete
>all those old channels with the "delete all on this source" button
>(or whatever it was called), since I wasn't planning to carry over the
>recordings from that unit---just the recording schedules---and since all
>those old channel numbers were wrong anyway.  -Those- channels are shown
>as deleted in the channels table, with the timestamp of when I deleted
>them.
>
>My -new- (Ceton) source apparently took up the ball of being source 3
>(and I have only one line in videosources, for source 3) and got all my
>new channels assigned there.  (Surprising.)  I noticed that yesterday
>when I realized that all my new recording files still started with 3.
>However, none of the channels I deleted using sdjson-sqlite-select
>are marked as deleted in the mysql channels table.
>
>I'm still wondering if there's some connecting link between the two
>which I have failed to invoke.  How does tv_grab_zz_sdjson_sqlite tell
>Myth which channels are valid?  What causes either one to stop fetching
>scheduling data for a channel?
>
>[Is it possible that sdjson-sqlite-select is failing to set some -second-
>field in the sqlite database when disabling a channel?  The code sets
>the "selected" field in the channels table in sqlite; I'm assuming that's
>sufficient unless that database schema has changed since s-s-s was written.]
>
>I'm hoping I don't have to manually use the channel editor to delete
>channels one by one; this was what I was trying to avoid by using
>sdjson-sqlite-select, since I wrote a couple simple scripts to do all
>the heavy lifting of emitting a list of -several hundred- callsigns to
>delete which I could then hand to sdjson-sqlite-select.  Now, I -could-
>manually set fake "deleted" entries on each such channel in the mysql
>channels table--that would be trivial---but I'd rather not, since direct
>DB manipulation is, uh, discouraged---precisely because I don't know
>what else happens when a channel gets deleted.  And also because it's
>cleaner to not have tv_grab_zz_sdjson_sqlite fetch twice as much data
>(or more) as it needs to.  (Or do XMLTV grabbers fetch -everything-,
>all the time, and it's Myth that determines whether to (a) store in
>mysql, and/or (b) to use, the resulting data?)
>
>I'd really appreciate an explanation of what deselecting a channel
>in an XML grabber is -supposed- to do (will its data still be fetched?
>does it somehow tell mfdb that the channel is to be deleted and/or
>otherwise ignored), or whether there are actually supposed to be
>two steps here:  (a) delete channel in grabber and (b) -also-
>delete same channel in myth, and the two don't talk to each other.
>
>P.S.  Either way, if sdjson-sqlite-select either doesn't work, or
>requires another step, someone with write access to the wiki should
>update the instructions.  If I figure this out, I'd so so, but I
>don't have edit rights on the wiki.
>
>P.P.S.  Second issue:  many of my HD channels appear twice in my channel
>map, in two different ranges (like 800's vs 1500's or whatever), and
>this seems to have been true for quite a while, so it's not some
>short-term shuffle going on.  I -think- either channel number works, but
>haven't had time to test that.  I don't know if there's a way of telling
>myth to prefer one or the other if it does turn out to matter.  I'm asking
>now because we're talking callsign/channel selection anyway and it might
>be relevent.

My understanding of XMLTV grabbers is that they all have a
$HOME/.mythtv/<source name>.xmltv file that contains a list of the
valid and invalid channels, and possibly some other config, which I do
not have any of in my simple tv_grab_nz-py grabber.  Each channel that
has a line of the form "channel=<xmltvid>" will have XMLTV EPG data
passed to whatever program calls the grabber (usually
mythfilldatabase).  Any channel in the EPG data that is not listed in
the .xmltv config file, or is listed as "channel!<xmltvid>" will not
get its EPG data sent to the calling program.  Beyond that, the .xmltv
config file has no effect on the MythTV setup - what channels are used
by MythTV is all controlled by the MythTV database.  Mythfilldatabase
will take the EPG data from the grabber and match the channels against
the mythconverg.channel table.  If there is a matching xmltvid, then
it will process that EPG data.  If there is no matching xmltvid, it
will discard that EPG data.  I believe that if a channel is deleted
(channel.deleted is not NULL), EPG data will be discarded for that
channel.  But I have not verified that.  For channels that are marked
with channel.visible=0, I am not sure if the EPG data gets processed
or discarded.  I only have two invisible channels and neither has EPG
available, so I can not tell what would happen if there was EPG data
for those channels.

My guess as to how the tv_grab_zz_sdjson_sqlite grabber works is that
it will use the list of valid channels to request the EPG data for
only those channels from SchedulesDirect.  The simple grabbers such as
the one I use normally just download an EPG file from somewhere and
then filter out the valid channels from that data, but doing it that
way for US cable systems would involve massive downloads that would
not be practical as most of the data would be being discarded.

If a channel is marked as channel.deleted!=NULL or channel.visible=0,
then I believe it will not have recordings scheduled for it, and will
not appear in the Guide.  However, mythweb has not been updated to
understand the channel.deleted field and deleted channels appear in
the channel editor under settings/tv/channels.  The new web interface
on port 6544 that is replacing mythweb may be a better option now as
it is kept updated, but I have not checked as mine is not accepting my
password to let me enter the settings pages.