Max Recordings = 1, 'Schedule as Group' combo causes conflicts

Platform: Linux Mint 21.3, 5.15.0-124-generic 134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
MythTV version: fixes/34
Package version:
Component:

What steps will reproduce the bug?

I have Manual Record rules to record two shows which air at the same time. One is "Tracker" on channel 189, and the other is "Ridley" on channel 191. Even though there are many available tuners, the Scheduler picked the same tuner, Prim0, to record both shows. BeforeFixSmall This is an HdHomerun Prime, using a cablecard, so multiplex recording is not possible. There are 3 tuners, and the cablecard can decrypt one channel per tuner. I have configured 3 Capture Cards for the HdHomerun Prime, Prim0, Prim1, Prim2. Here is the relevant portion of the Input Connections configuration for Prim0. Sched1 Note that I had the Schedule as Group option enabled. I'm not sure why. I didn't think it would matter with Max Recordings set to 1. In the text under Max Recordings, we're told that MythTV will only do multiplex recordings for values other than 1.

Each Sunday night, the supposed recording of "Tracker" would hold the contents of the "Ridley" show. There was one week when "Tracker" started early at 6:30pm. The recording had the correct show for half an hour, and then switched to "Ridley" in the middle of it.

I suspected that the Scheduler was improperly trying to do multiplex recordings, so I checked the database.

mysql> select channum, mplexid, callsign, sourceID from channel where mplexid=428;
+---------+---------+-----------------+----------+
| channum | mplexid | callsign        | sourceID |
+---------+---------+-----------------+----------+
| 368     |     428 | WTTW Vme        |        4 |
| 369     |     428 | WTTW Create     |        4 |
| 191     |     428 | WTTW - PBS - HD |        4 |
| 189     |     428 | WBBM HD         |        4 |
+---------+---------+-----------------+----------+
4 rows in set (0.00 sec)

The two channels, 189 and 191, do share the same multiplex ID.

mysql> SELECT cardid, displayname, parentid, schedgroup, reclimit FROM capturecard WHERE sourceid > 0 ORDER BY cardid;
+--------+-------------+----------+------------+----------+
| cardid | displayname | parentid | schedgroup | reclimit |
+--------+-------------+----------+------------+----------+
|     96 | Prim0       |        0 |          1 |        1 |
|     97 | Prim1       |        0 |          0 |        1 |
|     98 | Prim2       |        0 |          0 |        1 |
|     99 | Prim3       |        0 |          0 |        1 |
|    100 | Prim4       |        0 |          0 |        1 |
|    101 | Prim5       |        0 |          0 |        1 |
|    108 | Prim6       |        0 |          0 |        1 |
|    109 | Prim7       |        0 |          0 |        1 |
|    110 | Prim8       |        0 |          0 |        1 |
+--------+-------------+----------+------------+----------+
9 rows in set (0.00 sec)

Experimentation revealed that the Scheduler does not make this error when Schedule as Group is disabled. Sched2 AfterFixSmall

How often does it reproduce? Is there a required condition?

Always. Max Recordings = 1, 'Schedule as Group' = true, and two or more shows, sharing the same multiplex, set to record at the same time.

What is the expected behaviour?

The Scheduler should factor in the value of Max Recordings when deciding whether multiplex recording is allowed. If Max Recordings = 1, multiplex recording should not be allowed. Sched1 AfterFixSmall

What do you see instead?

"Tracker" and "Ridley" are scheduled to record at the same time on the same tuner. BeforeFixSmall

Additional information

Are you using your HDHR Prime(s) for clear QAM channels, ie. without a cablecard? That's the only case where you channels should have non-zero/null mplexids. If you are using a cablecard, your channels are definitely messed up. How did you populate the channels table?

To see why the scheduler does what it does, please run "mythbackend --testsched --verbose schedule --loglevel debug" and provide that output here.

Finally, your input table looks like you have 3 HDHR Primes. Is that correct? I'm just checking to make sure something else isn't wrong.

Long ago, I was the one who submitted the code to allow use of HdHomerun Prime clear QAM channels (without a cablecard). But soon after that, my cable company started encrypting every channel, so I got a cablecard. And I have added two more Primes with cablecards.

I populated the channels tables long ago, using a much older release of MythTv. I think, back then, the scanner didn't work with cablecard decryption, so I wrote my own code to get it to work. That's probably why my database has non-zero multiplexids.

I have a fix for this issue, but if it only exists due to my weird database, maybe it's not worth merging in.

I'll try doing a fresh scan using another computer, and see if it works after using the official scanning code.

That makes sense for how your channel table got to where it is. Fixing that will probably fix yor issue.

Also, I suggest you consider using Gary Buhrmaster's very fine, mythhdhrrecorder instead of the internal HDHR recorder. EVen after I fixed the internal recorder to properly share inputs long ago, I switched to using mythhdhrrecorder myself.

I installed the fixes/34 release. I deleted all the existing channel and dtv_multiplex rows. I tried running a Full Scan, which found no channels at all. Then I tried HDHomeRun Channel Import, which is really fast. This created a channel row for 397 channels known by the HdHomerun Prime.

mysql> select * from channel where channum='171';
+--------+---------+--------+----------+----------+-------+------+----------+--------------+---------+-------------+----------+------------+--------+-------+----------+---------+---------------+---------------+---------+-----------+--------------+----------+-----------------+-----------------+---------------------+-------------------+------------+--------+---------+
| chanid | channum | freqid | sourceid | callsign | name  | icon | finetune | videofilters | xmltvid | recpriority | contrast | brightness | colour | hue   | tvformat | visible | outputfilters | useonairguide | mplexid | serviceid | service_type | tmoffset | atsc_major_chan | atsc_minor_chan | last_record         | default_authority | commmethod | iptvid | deleted |
+--------+---------+--------+----------+----------+-------+------+----------+--------------+---------+-------------+----------+------------+--------+-------+----------+---------+---------------+---------------+---------+-----------+--------------+----------+-----------------+-----------------+---------------------+-------------------+------------+--------+---------+
| 120171 | 171     | NULL   |       12 | AMCHD    | AMCHD |      |     NULL |              |         |           0 |    32768 |      32768 |  32768 | 32768 | Default  |       1 |               |             1 |     147 |         1 |            0 |        0 |               0 |               0 | 0000-00-00 00:00:00 |                   |         -1 |   NULL | NULL    |
+--------+---------+--------+----------+----------+-------+------+----------+--------------+---------+-------------+----------+------------+--------+-------+----------+---------+---------------+---------------+---------+-----------+--------------+----------+-----------------+-----------------+---------------------+-------------------+------------+--------+---------+
1 row in set (0.00 sec)

It created one dtv_multiplex:

mysql> select * from dtv_multiplex;
+---------+----------+-------------+-----------+-----------+-----------+------------+------+----------+------------+-----------+--------------+-------------------+----------------+---------+---------------+-----------+--------------+-----------+---------+------------+----------------+---------------------+-------------------+
| mplexid | sourceid | transportid | networkid | frequency | inversion | symbolrate | fec  | polarity | modulation | bandwidth | lp_code_rate | transmission_mode | guard_interval | visible | constellation | hierarchy | hp_code_rate | mod_sys   | rolloff | sistandard | serviceversion | updatetimestamp     | default_authority |
+---------+----------+-------------+-----------+-----------+-----------+------------+------+----------+------------+-----------+--------------+-------------------+----------------+---------+---------------+-----------+--------------+-----------+---------+------------+----------------+---------------------+-------------------+
|     147 |       12 |           0 |         0 | 267000000 | a         |          0 | auto | v        | auto       | a         | auto         | a                 | auto           |       0 | auto          | a         | auto         | UNDEFINED | 0.35    | dvb        |             33 | 2024-11-06 19:49:18 |                   |
+---------+----------+-------------+-----------+-----------+-----------+------------+------+----------+------------+-----------+--------------+-------------------+----------------+---------+---------------+-----------+--------------+-----------+---------+------------+----------------+---------------------+-------------------+
1 row in set (0.00 sec)

Every one of the 397 channels has a mplexid set to match that single dtv_multiplex entry, 147.

That disproves your assertion that every channel should have a mplexid of zero.

The channel scan using fixes/34 doesn't really work though. None of the channels can be tuned in. I'll have to add my own code to set the channel using the hdhomerun_config <ID> set /tuner<n>/vchannel <vchannel> syntax. The official code doesn't do that, so I don't understand how it's supposed to work without a bunch of extra effort. Is the HDHomeRun Channel Import just a partial implementation?

As it stands. If I were able to tune in the discovered channels, each one would have the same mplexid, and the failure I described in this Issue would happen if Schedule as Group were set to true.

MythTV / mythtv