[mythtv-users] duplicates in dtv_multiplex

[Ross Boylan]

Thanks.  The original use of the code was to deal with channel
repacking, which may have been moves of the entire plex.  But, in
retrospect, the logic wasn't right even if I got away with it.
I think channel and dtv_multiplex are the only ones I need to update,
because those are the only ones I rewrote.

I was a bit concerned that getting them out of sync with the scan
information could cause trouble, but it sounds as if that's OK.

Since my original post I've discovered some code for handling rescans
with HDHR tuners, which is what I'm doing, e.g.
https://github.com/MythTV/mythtv/commits/a9465fe7c1c35499854549f0fd6b8b5a385aefe3.
Thanks @Klaas de Waal <klaas at kldo.nl>.  So imitating that seems like a
good idea.  It seems to follow a "use an existing plex if available,
otherwise create one" rule.

Ross

On Fri, Sep 22, 2023 at 1:56 AM Stephen Worthington
<stephen_agent at jsw.gen.nz> wrote:
>
> On Thu, 21 Sep 2023 10:39:21 -0700, you wrote:
>
> >My dtv_multiplex table has a few cases where the same frequency
> >appears in several mplexes:
> >
> >select mplexid, sourceid, transportid, networkid, frequency/1e6 as
> >MHz, visible, hierarchy, serviceversion, updatetimestamp from
> >dtv_multiplex order by frequency, updatetimestamp;
> >MariaDB [mythconverg]>
> >+---------+----------+-------------+-----------+------+---------+-----------+----------------+---------------------+
> >| mplexid | sourceid | transportid | networkid | MHz  | visible |
> >hierarchy | serviceversion | updatetimestamp     |
> >+---------+----------+-------------+-----------+------+---------+-----------+----------------+---------------------+
> >|      16 |        1 |         259 |      NULL |   79 |       0 | a
> >     |             33 | 2022-09-21 13:28:35 |
> >|       3 |        1 |         381 |      NULL |  207 |       0 | a
> >     |             33 | 2022-09-19 21:03:42 |
> >|       2 |        1 |         377 |      NULL |  207 |       0 | a
> >     |             33 | 2023-09-10 13:53:37 |
> >|       4 |        1 |         397 |      NULL |  213 |       0 | a
> >     |             33 | 2022-09-19 21:03:42 |
> >|       6 |        1 |         401 |      NULL |  213 |       0 | a
> >     |             33 | 2023-02-25 11:44:37 |
> >|       5 |        1 |        9739 |      NULL |  473 |       0 | a
> >     |             33 | 2022-09-19 21:03:42 |
> >|       7 |        1 |         385 |      NULL |  473 |       0 | a
> >     |             33 | 2023-02-25 11:44:37 |
> >|       8 |        1 |        4069 |      NULL |  515 |       0 | a
> >     |             33 | 2022-09-19 21:03:42 |
> >For example, mplexid's 3 and 2 refer to the same frequency.
> >Is this likely to cause any trouble?
> >If I take all the entries in the channel table that refer to mplexid 2
> >and change them to mplexid 3, and then delete the row
> >for mplexid 2 from the dtv_multiplex table, is that likely to cause
> >any trouble (assuming I don't do it when when of the affected channels
> >is recording)?
> >
> >Any direct change to these tables will put dtv_multiplex out of sync
> >with the scan information in channelscan_dtv_multiplex.
> >
> >This situation arose because a program I wrote to handle channel
> >packing and rearranging operates by rewriting the frequency of an
> >existing plex; mplexid 2 was presumably using a different frequency.
> >
> >I realized my update procedure wasn't quite right, and noticed this
> >problem while reviewing the code.  My thought is the code should be
> >moving the channels between existing plexes, or creating a new plex if
> >one doesn't exist.
> >In particular some atsc_major channels are split across different
> >plexes; a recent change split channels 4.1-4.5 across 3 different
> >frequencies.
>
> Dumping the database schema allows you to find all uses of the mplexid
> name:
>
> cd /tmp
> sudo mysqldump --no-data mythconverg > schema.sql
> less schema.sql
> /mplexid
>
> I can see it in these tables:
>
> channel
> channelscan_dtv_multiplex
> dtv_multiplex
> scan_channels
>
> so if you want to fix everything, you would need to fix those four
> tables.  However, I suspect that channelscan_dtv_multiplex and
> scan_channels can be ignored as they are only used for channel
> scanning, and you can just do a full scan the next time you need to do
> a scan.
>
> Yes, your code should not be changing the contents of dtv_multiplex
> rows like that - if it needs one with a different frequency to the
> existing ones, it should create a new one.  The only time you would
> want to change the frequency of an existing dtv_multiplex row would be
> if the entire multiplex had moved to a different frequency.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org