[mythtv-users] Tuners, conflicts and padding
Stephen Worthington
stephen_agent at jsw.gen.nz
Fri Jan 2 07:09:28 UTC 2015
On Thu, 01 Jan 2015 17:36:04 -0500, you wrote:
>On Jan 1, 2015, at 4:25 PM, E James <e_james at dsl.pipex.com> wrote:
>
>> I have 2 physical tuners and I have assigned 4 virtual tuners to each which means I can record 8 channels simultaneously so long as it's 4 per physical tuner. Tonight I wanted to record 3 channels from one multiplex and one from the other, so why am I getting conflict messages? What does "Conflict Today" mean? What does "Conflicting" mean? Why didn't the conflicts show up when I originally defined the recordings? With 2 "back to back" programmes on the same channel, does padding cause a conflict?
>
>
>“Conflict” means you have more shows matching rules than you have tuners to record them and “Conflict Today” is giving you a hint where to look to investigate the situation. With the typical two weeks of schedule data it borders on cruel to say “there’s a problem somewhere, you find it.”
>
>Thomas covered padding pretty well but I’m not clear why the scheduler wasn’t able to slot 3 shows onto 4 virtual tuners, I don’t think there’s a scenario where it can’t work that. You could look in the frontend’s setup menus under Recording Priorities - there’s an "Avoid back to back recordings” option that you can fiddle with and see if it helps. The default is “Never” but I have mine set to “Always” and it seems to do the right thing in all cases. It doesn’t sound applicable here but who knows.
>
>As to why the conflict didn’t show up earlier it could be you initially had generic episode data for that slot so myth figured it could pick up another showing but a later update brought specific episode information and myth glommed on to that showing.
>
>- George
With MythTV set to use its maximum of 5 virtual tuners per physical
tuner, real conflicts are unlikely with as many physical tuners as
there are multiplexes. Overlapping of recordings due to padding
potentially doubles the number of virtual tuners needed, so if you are
recording three programs at once from one multiplex, then the overlaps
could cause a conflict. And even then, MythTV would be able to use
the second physical tuner if it was not recording from the other
multiplex.
However, schedulers are extremely difficult and complex things to
write as software, and they are far from perfect. MythTV is no
exception, and when it has crowded tuners it can make a mistake and
assign both physical tuners to the same multiplex when it was not
necessary to, potentially leaving it without a tuner to assign to the
other multplex. I have seen this regularly here in New Zealand (with
3 multiplexes and 3 physical tuners) when particular lineups of
programs happen. The solution that one of the devs suggested which
has worked well for me is to make some powerpriority rules that give a
huge boost in priority to any program from multiplex 1 when recorded
on physical tuner 1 and a huge boost in priority to any program from
multiplex 2 when recorded on physical tuner 2 and so on. That works
around the problem of the scheduler assigning multiple physical tuners
to the same multiplex when it was unnecessary. This solution only
works when there are as many physical tuners as multiplexes.
So, first run mythtv-setup and make sure you have all the physical
tuners set to 5 virtual tuners - I am not sure if the default on
installation has 5 virtual tuners set. Then you might like to try
some rules like mine:
mysql> select * from powerpriority;
+----------------------+-------------+-------------------------------------------------------+
| priorityname | recpriority | selectclause |
+----------------------+-------------+-------------------------------------------------------+
| TVNZ multiplex | 20 | channel.mplexid=2 and cardinputid in (1,2,3,4,5) |
| Mediaworks multiplex | 20 | channel.mplexid=3 and cardinputid in (11,12,13,14,15) |
| Kordia multiplex | 20 | channel.mplexid=4 and cardinputid in (6,7,8,9,10) |
+----------------------+-------------+-------------------------------------------------------+
3 rows in set (0.00 sec)
Go to Setup > Video > Recording Priorities > Custom Priority to create
powerpriority rules. The priorityname is just for human use - choose
whatever you like. The recpriority value should be large enough to
outweigh any other combination of priority values you have used in
other priority settings, such as channel priorities. The selectclause
field is simply an SQL clause. To work out what you need there, will
first need to find which cardinputid values match each of your virtual
tuners. Mine are in order only because I fiddled with my database to
make them that way for ease of doing things like this. Yours will be
in whatever order mythtv-setup created them. If you are up for doing
SQL, this command will show you what you need:
mysql> select ci.cardid,cardinputid,videodevice,cardtype from
capturecard cc,cardinput ci where cardtype='DVB' and
ci.cardid=cc.cardid order by videodevice,cc.cardid;
+--------+-------------+-----------------------------+----------+
| cardid | cardinputid | videodevice | cardtype |
+--------+-------------+-----------------------------+----------+
| 1 | 1 | /dev/dvb/adapter0/frontend0 | DVB |
| 2 | 2 | /dev/dvb/adapter0/frontend0 | DVB |
| 3 | 3 | /dev/dvb/adapter0/frontend0 | DVB |
| 4 | 4 | /dev/dvb/adapter0/frontend0 | DVB |
| 5 | 5 | /dev/dvb/adapter0/frontend0 | DVB |
| 6 | 6 | /dev/dvb/adapter1/frontend0 | DVB |
| 7 | 7 | /dev/dvb/adapter1/frontend0 | DVB |
| 8 | 8 | /dev/dvb/adapter1/frontend0 | DVB |
| 9 | 9 | /dev/dvb/adapter1/frontend0 | DVB |
| 10 | 10 | /dev/dvb/adapter1/frontend0 | DVB |
| 11 | 11 | /dev/dvb/adapter2/frontend0 | DVB |
| 12 | 12 | /dev/dvb/adapter2/frontend0 | DVB |
| 13 | 13 | /dev/dvb/adapter2/frontend0 | DVB |
| 14 | 14 | /dev/dvb/adapter2/frontend0 | DVB |
| 15 | 15 | /dev/dvb/adapter2/frontend0 | DVB |
| 17 | 17 | /dev/dvb/adapter3/frontend0 | DVB |
| 18 | 18 | /dev/dvb/adapter3/frontend0 | DVB |
| 19 | 19 | /dev/dvb/adapter3/frontend0 | DVB |
| 20 | 20 | /dev/dvb/adapter3/frontend0 | DVB |
| 21 | 21 | /dev/dvb/adapter3/frontend0 | DVB |
| 22 | 22 | /dev/dvb/adapter4/frontend0 | DVB |
| 23 | 23 | /dev/dvb/adapter4/frontend0 | DVB |
| 24 | 24 | /dev/dvb/adapter4/frontend0 | DVB |
| 25 | 25 | /dev/dvb/adapter4/frontend0 | DVB |
| 26 | 26 | /dev/dvb/adapter4/frontend0 | DVB |
| 27 | 27 | /dev/dvb/adapter5/frontend0 | DVB |
| 28 | 28 | /dev/dvb/adapter5/frontend0 | DVB |
| 29 | 29 | /dev/dvb/adapter5/frontend0 | DVB |
| 30 | 30 | /dev/dvb/adapter5/frontend0 | DVB |
| 31 | 31 | /dev/dvb/adapter5/frontend0 | DVB |
| 32 | 32 | /dev/dvb/adapter6/frontend0 | DVB |
| 33 | 33 | /dev/dvb/adapter6/frontend0 | DVB |
| 34 | 34 | /dev/dvb/adapter6/frontend0 | DVB |
| 35 | 35 | /dev/dvb/adapter6/frontend0 | DVB |
| 36 | 36 | /dev/dvb/adapter6/frontend0 | DVB |
+--------+-------------+-----------------------------+----------+
35 rows in set (0.00 sec)
In my case, only the first three DVB tuners (adapter0 to adapter2) are
DVB-T - the rest are DVB-S. In each of your two powerpriority rules,
you will need to list all the cardinputid values associated with the
corresponding DVB-T tuner (presumably adapter0 and adapter1).
This command will show you the mplexid values you need:
mysql> select mplexid,sourceid,transportid,networkid,frequency from
dtv_multiplex order by mplexid;
+---------+----------+-------------+-----------+-----------+
| mplexid | sourceid | transportid | networkid | frequency |
+---------+----------+-------------+-----------+-----------+
| 1 | 1 | 34 | 8746 | 530000000 |
| 2 | 1 | 27 | 8746 | 578000000 |
| 3 | 1 | 29 | 8746 | 562000000 |
| 4 | 1 | 33 | 8746 | 594000000 |
| 5 | 3 | 21 | 47 | 12456000 |
| 6 | 3 | 22 | 47 | 12483000 |
| 7 | 4 | 1 | 169 | 12581000 |
| 8 | 4 | 2 | 169 | 12608000 |
| 9 | 4 | 3 | 169 | 12519000 |
| 10 | 4 | 4 | 169 | 12546000 |
| 11 | 4 | 5 | 169 | 12644000 |
| 12 | 4 | 6 | 169 | 12671000 |
| 13 | 4 | 7 | 169 | 12331000 |
| 14 | 4 | 8 | 169 | 12358000 |
| 15 | 4 | 9 | 169 | 12267000 |
| 16 | 4 | 10 | 169 | 12295000 |
| 17 | 4 | 11 | 169 | 12707000 |
| 18 | 4 | 12 | 169 | 12734000 |
| 19 | 4 | 13 | 169 | 12394000 |
| 20 | 4 | 14 | 169 | 12421000 |
+---------+----------+-------------+-----------+-----------+
20 rows in set (0.00 sec)
Again, in my case only the multiplexes with sourceid=1 are DVB-T - the
rest are DVB-S. You should have two valid mplexid values, both
presumably with the same sourceid. They will not necessarily be 1 and
2, depending on what you did when you set up your channels. I fiddled
my dtv_multiplex table also to produce an easy to understand
arrangement of my multiplexes.
In order to easily use SQL on my mythconverg database, I created a
script file that gives me access. You might like to try using it if
you are not familiar with SQL. I use Mythbuntu, so it is set up for
that - you did not say what you are using but Mythbuntu users seem to
be the most common users of MythTV.
I have put a copy of my script on my web server here:
http://www.jsw.gen.nz/mythtv/do_mythconverg.sh
It can be put in the /usr/local/bin directory. Make sure you give it
executable permissions. These commands from a root prompt or with
sudo in front of the wget and chmod will set it up:
cd /usr/local/bin
wget http://www.jsw.gen.nz/mythtv/do_mythconverg.sh
chmod a+x do_mythconverg.sh
You will likely also have to install the xmlstarlet package - the
script will tell you if it is not installed.
WARNING: Unless you know what you are doing, only use the read-only
SQL commands (such as "show", "desc" and "select") as it is easy to
corrupt databases if you try to manipulate them directly from SQL.
More information about the mythtv-users
mailing list