Mailing List Archive

Clunky tuner detection in mythtvsetup
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




_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
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@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.
_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On 08/08/17 10:52, John Pilkington 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
>
Mythtv fixes/29 (and master 30pre) allows multirec of upto 10
(previously 5).

The way Capture cards are provisioned has changed in fixes/29 and
Master (from 0.28/Fixes) in that the maximum number of recordings is now
set in Input Connections rather than Capture Cards. There is a side
effect which means the order of creation is important otherwise tuners
may not be efficiently used. Capture Card needs to be fully configured
before adding the next one i.e. Create Capture Card, Create Video
Source, Create Input Connections, then do the next Capture Card. In
0.28/Fixes I was used creating all Capture Cards then Video Sources,
followed by Input Connections.


Mike

Apologies for the direct email response to John P
_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On 08/08/17 15:22, Stephen Worthington wrote:
> 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?
>>
Stephen: Thanks for your very comprehensive reply. Well worth reading
although I've cut it here.

Multirec can be > 5 in master - the higher value gets used mainly by my
radio recordings.

I have a dvb.conf file which works with that el7.elrepo kernel but
didn't the last time I used a standard el7 kernel.

I suspect that some of my dropped or misplaced packets happen because
trees are growing on my sight line and the pci-card or its driver just
copes better. Everything comes through the same aerial and preamp, with
various splitters after. Do you have away of detecting buffer-overruns?

I did edit the DB entries when code changes lost multirec early last
year, and I may well try it now, but it's not a good general solution.
And I did consider clearing everything for a fresh start - but was
initially hoping for a quick fix.

I had the impression that the disecq and upnp delays were going up with
my multirec numbers. I've found some of the code but as yet it's not
entirely clear...

Cheers,

John
_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On Tue, 8 Aug 2017 16:10:56 +0100, you wrote:

>On 08/08/17 15:22, Stephen Worthington wrote:
>> 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?
>>>
>Stephen: Thanks for your very comprehensive reply. Well worth reading
>although I've cut it here.
>
>Multirec can be > 5 in master - the higher value gets used mainly by my
>radio recordings.
>
>I have a dvb.conf file which works with that el7.elrepo kernel but
>didn't the last time I used a standard el7 kernel.
>
>I suspect that some of my dropped or misplaced packets happen because
>trees are growing on my sight line and the pci-card or its driver just
>copes better. Everything comes through the same aerial and preamp, with
>various splitters after. Do you have away of detecting buffer-overruns?
>
>I did edit the DB entries when code changes lost multirec early last
>year, and I may well try it now, but it's not a good general solution.
>And I did consider clearing everything for a fresh start - but was
>initially hoping for a quick fix.
>
>I had the impression that the disecq and upnp delays were going up with
>my multirec numbers. I've found some of the code but as yet it's not
>entirely clear...
>
>Cheers,
>
>John

To get reports of bad recordings, you can add the -v record option to
your mythbackend command line. That will then cause log entries like
this:

Aug 8 19:04:01 mypvr mythbackend: mythbackend[3506]: I TVRecEvent
tv_rec.cpp:849 (FinishedRecording) TVRec[12]:
FinishedRecording(1003_2017-08-08T06:07:00Z) good
recq:<RecordingQuality overall_score="0.970755"
key="1003_2017-08-08T06:07:00Z" countinuity_error_count="4"
packet_count="22009720">#012 <Gap start="2017-08-08T06:07:00Z"
end="2017-08-08T06:07:31Z" duration="31" />#012</RecordingQuality>

Not all gaps are reported however - you can still get very short gaps
that cause short visual or audible playback problems that will not be
detected by whatever method mythbackend is using for those reports.

When you get large Gap errors reported like that, it is normally due
to buffer overruns, but there is no specific way to tell them from a
long rain fade on a satellite dish.

To prevent buffer overruns, I use a rule of thumb that I do not want
more than two recordings to one hard drive at the same time. It seems
that I can get away with twice that many recordings for a few minutes,
as that happens when recordings overlap on a channel due to pre-roll
and post-roll. But sustained recording to three or more files at once
to one hard drive seems to be too much.

Another strategy for doing huge numbers of simultaneous recordings
would be to do them to a fast SSD (eg NVME PCIe SSD). Then once the
recordings are complete and there is a suitable gap between
recordings, the recording files can be moved off to spinning rust by
another program. I have not tried this due to not having enough space
on my fast SSD for doing many recordings, but the figures for
sustained write speeds to NVME PCIe SSDs are such that it should work.

The main problem with rotating disks is not the write speed - that is
quite sufficient. It comes from having to move the heads between the
locations of the different recordings, and also to periodically update
the directory areas of the disk as the files are expanded. Hard
drives have become very fast while on track, but the track to track
stepping speeds have only increased slightly over the years. Since
SSDs do not have any heads to move, they should solve that problem
nicely.

If anyone wants to try recording to SSD and then moving the recordings
automatically during recording gaps, I have some Python code that I
use for moving recordings around that automatically stops when a gap
ends. And I also have code for detecting upcoming recording gaps and
how long they are. I would be happy to help create a program using
those bits of code that could do what is required.
_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On 08/08/17 16:10, John Pilkington wrote:
> On 08/08/17 15:22, Stephen Worthington wrote:
>> 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?
>>>
> Stephen: Thanks for your very comprehensive reply. Well worth reading
> although I've cut it here.
>
> Multirec can be > 5 in master - the higher value gets used mainly by my
> radio recordings.
>
> I have a dvb.conf file which works with that el7.elrepo kernel but
> didn't the last time I used a standard el7 kernel.
>
> I suspect that some of my dropped or misplaced packets happen because
> trees are growing on my sight line and the pci-card or its driver just
> copes better. Everything comes through the same aerial and preamp, with
> various splitters after. Do you have away of detecting buffer-overruns?
>
> I did edit the DB entries when code changes lost multirec early last
> year, and I may well try it now, but it's not a good general solution.
> And I did consider clearing everything for a fresh start - but was
> initially hoping for a quick fix.
>
> I had the impression that the disecq and upnp delays were going up with
> my multirec numbers. I've found some of the code but as yet it's not
> entirely clear...
>
> Cheers,
>
> John

cardutil.cpp has lots of ifdefs which I might try unsetting for personal
use - if I knew how to do it.

Here's what I ended up with. It looks probably ok, but it's scheduling
14 and 15 for the second mux, when I intended 8 and 9. I'll try it for
a few days.

MariaDB [mythconverg]> select cardid, parentid, videodevice, schedorder,
livetvorder
-> from capturecard ;
+--------+----------+-----------------------------+------------+-------------+
| cardid | parentid | videodevice | schedorder |
livetvorder |
+--------+----------+-----------------------------+------------+-------------+
| 1 | 0 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 2 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 3 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 4 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 5 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 6 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 7 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 8 | 1 | /dev/dvb/adapter0/frontend0 | 1 |
8 |
| 9 | 0 | /dev/dvb/adapter2/frontend0 | 13 |
17 |
| 10 | 9 | /dev/dvb/adapter2/frontend0 | 13 |
17 |
| 11 | 9 | /dev/dvb/adapter2/frontend0 | 13 |
17 |
| 12 | 9 | /dev/dvb/adapter2/frontend0 | 13 |
17 |
| 13 | 9 | /dev/dvb/adapter2/frontend0 | 13 |
17 |
| 14 | 0 | /dev/dvb/adapter1/frontend0 | 8 |
12 |
| 15 | 14 | /dev/dvb/adapter1/frontend0 | 8 |
12 |
| 16 | 14 | /dev/dvb/adapter1/frontend0 | 8 |
12 |
| 17 | 14 | /dev/dvb/adapter1/frontend0 | 8 |
12 |
| 18 | 14 | /dev/dvb/adapter1/frontend0 | 8 |
12 |
+--------+----------+-----------------------------+------------+-------------+
18 rows in set (0.01 sec)





_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On 09/08/17 11:14, John Pilkington wrote:
<snip>
> MariaDB [mythconverg]> select cardid, parentid, videodevice, schedorder,
> livetvorder
> -> from capturecard ;
> +--------+----------+-----------------------------+------------+-------------+
>
> | cardid | parentid | videodevice | schedorder |
> livetvorder |
> +--------+----------+-----------------------------+------------+-------------+
>
> | 1 | 0 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 2 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 3 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 4 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 5 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 6 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 7 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 8 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
> | 9 | 0 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
> | 10 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
> | 11 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
> | 12 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
> | 13 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
> | 14 | 0 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
> | 15 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
> | 16 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
> | 17 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
> | 18 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
> +--------+----------+-----------------------------+------------+-------------+
>
> 18 rows in set (0.01 sec)

Revision:
MariaDB [mythconverg]> update capturecard set livetvorder=7 where cardid=1 ;

and so on for cardids 2 to 8. Sorry about all this noise.





_______________________________________________
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: Clunky tuner detection in mythtvsetup [ In reply to ]
On 09/08/17 11:39, John Pilkington wrote:
> On 09/08/17 11:14, John Pilkington wrote:
> <snip>
>> MariaDB [mythconverg]> select cardid, parentid, videodevice, schedorder, livetvorder
>> -> from capturecard ;
>> +--------+----------+-----------------------------+------------+-------------+
>> | cardid | parentid | videodevice | schedorder | livetvorder |
>> +--------+----------+-----------------------------+------------+-------------+
>> | 1 | 0 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 2 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 3 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 4 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 5 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 6 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 7 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 8 | 1 | /dev/dvb/adapter0/frontend0 | 1 | 8 |
>> | 9 | 0 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
>> | 10 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
>> | 11 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
>> | 12 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
>> | 13 | 9 | /dev/dvb/adapter2/frontend0 | 13 | 17 |
>> | 14 | 0 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
>> | 15 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
>> | 16 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
>> | 17 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
>> | 18 | 14 | /dev/dvb/adapter1/frontend0 | 8 | 12 |
>> +--------+----------+-----------------------------+------------+-------------+
>> 18 rows in set (0.01 sec)
>
> Revision:
> MariaDB [mythconverg]> update capturecard set livetvorder=7 where cardid=1 ;
>
> and so on for cardids 2 to 8. Sorry about all this noise.
>
Actually, that would have made no difference at all, since the other values are all higher than 7.

--

Mike Perkins

_______________________________________________
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