[mythtv-users] schedule howto

Mike Perkins mikep at randomtraveller.org.uk
Fri Dec 8 16:27:00 UTC 2023

On 08/12/2023 15:56, Stephen Worthington wrote:
> 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.
There is a possible confusion here between virtual /tuners/ and virtual /channels/. I agree that 
whether a tuner is 'virtual' or not is going to make any difference, it is all the same code.

However, virtual /channels/ could be a different problem, depending on specific language. In the US 
I know they call those 'subchannels' and it is likely that some or most have lower bitrates to cram 
more subchannels in. I don't know if the same applies in AU, but that could be the problem.

Alternatively, it is simply possible that the signal is not strong enough and sometimes drops out. 
Perhaps a tweak to the antenna direction, check all the joints for soundness and/or water, etc? That 
might go a long way to solving the problem.


Mike Perkins

More information about the mythtv-users mailing list