[mythtv-users] Clunky tuner detection in mythtvsetup

[Stephen Worthington]

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.