[mythtv-users] schedule howto

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Dec 8 15:56:45 UTC 2023


On Fri, 8 Dec 2023 20:55:31 +0800, you wrote:

>G’day all
>playing with the rules I can solve once, but everytime is a pain 

>
>Aprogram (news on Australian ABC) scheduled to record from 1900 to 2000 (ish)
>Bprogram scheduled 1930 to 2230
>
>Aprogram (daily) can be on any combination of 2, 20, 21, 22, 23
>My hardware causes some virtual channels to sometimes record broken recordings (badly pixelated) as a result I’ve set <no> virtual channels.
>As suggested I put “prefer HD”
>
>Now Aprogram records on tuner one, two, three, four
>One recording of News is [red] conflict
>One recording of Bprogram is [red] conflict
>
>Wunce-upon-a-time I recall a rule “record 1 showing only”. That with “Prefer HD” would completely solve my problem. What is the solution? Better tuners, they are Haupauge USB dual tuners.
>
>James
>
>PS I can't give prority to any 2, 20-23, that channel may not carry Aprogram 

How sure are you that the pixelation is caused by virtual tuners? Most
people do not have that problem, and there are plenty of users of
Hauppauge USB tuners.  The way that virtual tuners work is just to
allow more than one set of streams to be recorded at the same time
from the same tuner.  So the tuner hardware gets told to send streams
a,b, and c to the PC for one channel and streams f, g, and h for
another channel.  It sends all those streams at once to the CPU.  The
CPU sorts out which streams are for which channel and writes them to
separate recording files.  The only problem you could get from getting
the tuner to send more streams is if the total bit rate exceeded the
maximum for USB 2.0, which is not possible for a DVB-T transmitter,
especially an Australian one that operates on 7 MHz bandwidth where
the rest of the world mostly uses 8 MHz.

When you set virtual tuners to 0, all you are doing is telling
mythbackend to record from effectively one virtual tuner, in other
words, record all the streams for one channel only from the tuner. But
the same code is used as when multiple virtual tuners is specified.

So your problem is more likely to be at the other end of things - if
you write too many recordings at once to a hard drive, you will
eventually get to the point where the heads will not be able to move
between the file locations fast enough to keep up, and mythbackend's
recording buffers will overflow before all the data can be written to
disk.  Which causes gaps in the data, which you see as pixellation and
missing bits, and it also causes glitches in the sound.  If this is
happening, you should be getting bad recordings for all the recordings
going to the overloaded hard disk during the time it was overloaded. I
have been there and done that.

So how many recordings are you writing to disk when you are getting
pixilated recordings?  How many disks are they going to?  How fast are
the disks?

If this is what your problem is, then the solution is normally just to
had another hard drive to the PC.  I have 7 recording drives in order
to prevent this problem.  To be completely sure not to get overloaded
hard drives, I work on the basis that there should be only 2
recordings at once going to one hard drive.  That then allows for
playback of another recording from the same drive while those two
recordings are in progress.  In theory, the faster more recent hard
drives should be able to cope with 3 recordings at once plus playback,
or maybe more, but I have never tested that.  I still have 2 old hard
drives that probably can not do that, but I keep them as they are very
quiet compared to more modern ones, so I can use them for the
relatively few overnight recordings and not have the hard drive noises
keep me awake.

Along with recordings and playback, there can be other hard disk
activity for commercial skip processing.  Modern CPUs can normally
cope with doing commercial skip processing in real-time from the
in-memory recording buffers on the basis of one core per recording.
Such processing does not cause any extra hard disk activity.  If you
are making more recordings at once than you have CPU cores, you
normally set the number of commercial skip processes to the number of
cores, and the extra recordings get scheduled for later processing. In
which case, the commercial skip processes will be reading back those
recordings from hard disk at a speed significantly greater than for
playback or recording.  And that can interfere with any recordings
going on at the time as the heads will be moving back and forth quite
a bit.  I do not have this problem as I do not do any commercial skip
processing - it does not work usefully on any New Zealand channels
that I know of.


More information about the mythtv-users mailing list