[mythtv-users] Clunky tuner detection in mythtvsetup

[Stephen Worthington]

On Tue, 8 Aug 2017 10:52:18 +0100, you wrote:

>I have two devices with three DVB-T tuners on this box, running 30pre3 
>with the 4.4.79-1.el7.elrepo.x86_64 kernel.
>
>$ dmesg | grep adapt
>[   18.492232] DVB: registering new adapter (Kworld UB499-2T T09)
>[   18.497274] usb 1-1: DVB: registering adapter 1 frontend 0 (Afatech 
>AF9033 (DVB-T))...
>[   18.500472] DVB: registering new adapter (Kworld UB499-2T T09)
>[   18.516789] usb 1-1: DVB: registering adapter 2 frontend 0 (Afatech 
>AF9033 (DVB-T))...
>[   20.417032] DVB: registering new adapter (saa7133[0])
>[   20.417041] saa7134 0000:07:04.0: DVB: registering adapter 0 frontend 
>0 (Philips TDA10046H DVB-T)...
>
>The adapter error rates vary, 0 being the best and 2 the worst.  I aim 
>to have multirec settings of 8, 5, 5.  I have had this in the past but 
>recent trials had upset things;  yesterday I saw a gap in the schedule 
>and tried to improve matters.  It was a frustrating experience and I'm 
>not yet sure that I got what I wanted: a simple and logical assignment 
>of 'virtual tuner' numbers.
>
>The card identification process showed the type but probing often failed 
>to show the device identifier, and restarts always involved lengthy 
>searches for disecq trees and upnp devices like VBox, which I know I 
>don't have.  The kernel identified my hardware soon after boot.
>
>There was some work on this sort of thing at Ticket #12547 but setup is 
>typically done once and then forgotten.  Have I missed some shortcuts?
>
>John P

I thought the max multirec setting was 5 - has this changed?

If you want to get a logical setup for your tuners with mythtv-setup,
then you have to delete them all and start again - I think that may
mean a complete delete which would remove all the sources and channels
too, which I never want to do as it is too hard to set them all up
properly again.  So when I wanted to adjust my tuners, I'm afraid I
used an database editor and did it manually in the database, having
shut down mythbackend and done a full backup first.  With a good GUI
database/SQL editor, it is not too difficult once you understand how
the tables for the tuners work.

Before doing that though, you need make sure the tuners are assigned
to the same /dev/dvb devices each boot.  A lot of the tuner drivers
have an option adapter_nr that allows you to do that, as long as the
tuners use different drivers.  Otherwise you can try using udev rules.
This is what I have for my tuners:

root at mypvr:/mnt# cat /etc/modprobe.d/options-dvb.conf
#Options for the /dev/dvb cards

#Set adapter numbers for AverMedia AverTV DVB-T Volar USB tuner and
Nova-TD 500 DVB-T card (dual tuners) (they use the same driver).
options dvb_usb_dib0700 adapter_nr=0,1,2

##Set adapter number for TurboSight TBS5922 QBOX S2 DVB-S2 USB tuner.
#options dvb-usb-tbsqbox22 adapter_nr=3

##Set adapter number for TeVii S470 DVB-S2 PCIe x1 card.
##options cx23885 adapter_nr=4 debug=9 v4l_debug=9
#options cx23885 adapter_nr=4

# TBS6909 8 tuner DVB-S2 card
options mxl5xx mode=1 inputs=1,1,1,1
#options mxl5xx mode=0
options tbsecp3 adapter_nr=7,8,9,10,11,12,13,14

In my case, the DVB-T tuners on the dvb_usb_dib0700 driver all come up
in the same order every time, courtesy of how the kernel enumerates
the USB ports in the same order every time.  So the AverMedia AverTV
DVB-T Volar USB tuner is always /dev/dvb/adapter0 and the dual tuners
of the Nova-TD 500 DVB-T PCI card (which has its own USB hub on board)
are always adapter1 and adapter2, and in the same order.  If I move
the AverMedia tuner to a different USB port, it still comes up as
adapter0 as the kernel enumerates all the motherboard USB hubs before
it enumerates the PCIe or PCI ones.  If I were to add another dib700
based USB tuner, it would then have indeterminate order with the
AverMedia tuner depending on which USB ports they were plugged into,
but they would always be in the same order as long as they were on the
same USB ports.

Varying DVB-T adapter error rates usually relate to how sensitive a
card is, and what signal level you are providing to each tuner.  If
you can provide each tuner with adequate (but not too high) signal,
then they should all have similar error rates when run from the same
aerial.  That means that if you have say 3 tuners and a TV to run from
the same aerial, you need to use a 4 way splitter to do the job, and
may need a little amplifier before the splitter to get the signal
level right.  People often use a two way splitter for the TV and the
tuners, and a second splitter for the tuners under the two way
splitter.  Then they complain that the TV is working fine but the
tuners are not, and blame the tuners, when the tuners in fact have
much less signal level than the TV.

And if one of your tuners is a dual tuner with its own on-board
splitter (it has only one aerial input for two tuners), then you have
to take that into account too, as each of the dual tuners will be
getting only half the signal level provided to the other single
tuners.  In which case you might want to use a more complex splitter
arrangement that equalised the signal levels.

However, people also often mistake disk buffer overrun errors for
tuner errors.  They look very similar when playing back a recording,
as they cause the same effect - missing data in the recording file.
But if you are trying to record 5 things at once to one spinning hard
disk, it is likely not able to do that and data will get dropped from
time to time.  So if you have lots of tuners and they do lots of
multirec recordings on each at the same time, then you also need lots
of hard drives to record to, or you will get errors.  I have seven
recording drives for that reason, and I think I probably need an
eighth one as I have been having some errors recently that appear to
be happening when I am recording many channels at once.  The errors
are happening on my highest bit rate HD channel, which is suggestive
of disk buffer overrun errors, but I have not debugged the problem
properly yet, due to lack of time and the errors not being bad enough.