[mythtv-users] input selection based upon season

[Stephen Worthington]

On Sun, 22 Dec 2019 13:49:12 -0600, you wrote:

>I have one channel that available on two different inputs. I would
>prefer to record the OTA signal using the PVR-2250 except that during
>the growing season reception is poor at sunrise/sunset. I attribute it
>to the relative placement of the sun and the transmitter creating too
>much noise and foliage on the trees blocking the signal. I have a high-
>gain antenna, but it sits behind a hill. The secondary input is a
>rebroadcast over cable (Charter/Spectrum) that I record using an ETH6.
>Using the secondary input causes scheduling conflicts with other
>recordings. I have been manually changing recpriority of the OTA
>channel twice each year to force the input selection.
>
>Is there a way that I can automate the input selection based upon
>season (day of year)? Or is there some better way that I haven't
>envisioned?
>
>Thanks,
>Stephen

That sort of thing is what the powerpriority table in the database is
used for.  In mythfrontend, go to Setup > Video > Recording Priorities
> Custom Priority.  In there, you can create SQL code to adjust the
priorities that the scheduler uses.  So you would be able to use SQL
to say add 100 to the priority when the date and time is in a certain
range and a programme is going to record from the problem channel, if
the channel records from the cable tuner(s).

Here is what I have in my powerpriority table:

MariaDB [mythconverg]> select * from powerpriority;
+----------------------------+-------------+--------------------------------------------------------------+
| priorityname               | recpriority | selectclause                                                 |
+----------------------------+-------------+--------------------------------------------------------------+
| TVNZ multiplex             |          20 | channel.mplexid=2 and cardid in (1,2,3,4,5)                  |
| Mediaworks multiplex       |          20 | channel.mplexid=3 and cardid in (11,12,13,14,15)             |
| Kordia multiplex           |          20 | channel.mplexid=4 and cardid in (6,7,8,9,10)                 |
| Kordia 2 multiplex         |          20 | channel.mplexid=1 and cardid in (16,17,18,19,20)             |
| Kordia 3 (Maori) multiplex |          20 | channel.mplexid=21 and cardid in (21,22,23,24,25)            |
| Prime                      |          20 | channel.callsign like 'PRIME%' and cardid>=90 and cardid<=91 |
+----------------------------+-------------+--------------------------------------------------------------+
6 rows in set (0.00 sec)

The first 5 rules give a priority boost when a recording is done for a
particular multiplex (frequency) when it is done on a particular
physical tuner.  My cardid values are all assigned in order, so
cardids 1-5 are on my first DVB-T2 tuner, 6-10 on the second and so
on.  So the result of those rules is that each of the DVB-T 5
multiplexes I receive from is effectively assigned to its own physical
tuner (I have an 8 tuner DVB-T2 card).

The Prime rule gives a priority boost to recordings on the PRIME,
PRIME HD and PRIME+1 channels if they record on cardid 90 or 91, which
is my first SAT>IP network tuner.  That is my most reliable SAT>IP
tuner.

If you do not do SQL, let me know and I can help you with that.  There
is a limit to the number of characters in the selectclause field
(16000 characters), but you can get around even that by using stored
functions where the SQL is stored in the database and called from the
select clause field.  So you can have as complicated SQL code as you
like.  However, every time the scheduler runs, it will have to run
this code, so simpler is better to reduce the time the scheduler takes
to create the recording schedule.