Mailing List Archive: duplicates in dtv

duplicates in dtv_multiplex

Sep 21, 2023, 10:39 AM

Post #1 of 3 (119 views)

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.

Thanks.
Ross
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: duplicates in dtv_multiplex [ In reply to ]

stephen_agent at jsw

Sep 22, 2023, 1:55 AM

Post #2 of 3 (116 views)

Permalink

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@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: duplicates in dtv_multiplex [ In reply to ]

rossboylan at stanfordalumni

Sep 22, 2023, 11:35 AM

Post #3 of 3 (116 views)

Permalink

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@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@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@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org