[mythtv-users] padding question
stephen_agent at jsw.gen.nz
Thu Dec 7 05:08:56 UTC 2017
On Wed, 06 Dec 2017 20:05:28 -0800, you wrote:
>thanks for the reply. again i have no padding set, preroll or postroll
>on any of the rules themselves or in the setup/video/general/advanced.
>they are all zero. i still don't understand given what you are saying
>why the earlier show would run over. i have not changed anything in the
>setup of tuners / mulitrecs since i set it up years ago, and it never
>did this before. it changed somewhere in an update at .28. on the ota,
>it is rare that i would want to record off of a single channel with sub
>channels as the quality and content of those subs is not what i am
>usually recording, i set it at two as that is the most i have ever
>needed. this is not qam, this is ota channels. i appreciate the
>explanation. but still don't understand why with no front or back
>padding the earlier shows on only the same channel are running over.
You are working under a misapprehension about subchannels. They are
not actually "sub" channels, they are just channels. The main and sub
channel names are something that seems to be used in the American
market, but ATSC transmissions (like DVB-T) can broadcast as many
channels on one frequency (one multiplex) as they can fit in the
available bandwidth. A multiplex is just a stream of digital data,
divided up into packets. Each packet is tagged to say what it is,
audio, video, subtitles or something more esoteric, and which channel
that packet stream belongs to. So to record a channel, the software
simply looks for all the packets tagged as belonging to that channel
and stores them to disk in the recording file. For one TV channel,
there will normally be a stream of audio packets and a stream of video
packets, and sometimes some more streams (subtitles, audio for
alternate languages, 5.1 or 7.1 audio, teletext, ...).
The total bandwidth used by all the streams for all the channels on a
multiplex can not ever instantaneously exceed the available bandwidth
for the multiplex. But within that bandwidth, the transmitter can
vary the bandwidth used by each stream as it likes. So a channel can
be transmitting at high bandwidth because it is broadcasting an HD
program, and then it might switch to a lower bandwidth for a while
during an ad break as the ads being transmitted are only SD format.
During that period, when that channel is low bandwidth, it would be
possible for another channel on the multiplex to switch to a higher
bandwidth (eg to do HD ads), as long as the total bandwidth used is
still within the limit.
It is not usual to switch bandwidths like that, but it is supported by
the ATSC (and DVB-T) standards. What is usual is that on any
multiplex there will be one or two channels that normally broadcast in
high bandwidth in order to transmit HD programs, and several other
channels that normally broadcast in lower bandwidth and only transmit
SD programs. But the actual bandwidth used by each channel can vary,
so if there are two HD channels, one might be broadcasting at say 9000
kbyte/s and one might be only broadcasting at 8000 kbytes/s. The same
applies to SD channels - if they want to squeeze in an extra channel,
they can reduce the quality of the video on the other channels on the
multiplex by doing heavier compression, and fit in the extra channel.
That does reduce the visual quality of the other channels, and when
that happens, they may well get complaints about it.
In the USA, the right to use one multiplex seems to be assigned to one
company, and only they can transmit on that frequency. They typically
seem to have one main flagship channel, broadcasting in HD, and
several other channels that they transmit, including possibly a +1
hour copy in SD of their HD channel. Some of the other channels can
be produced by that company, or they may have a deal with other
providers to transmit channels for them. From that seems to come the
naming of "main" and "sub" channels, with the flagship HD channel
being called the "main" channel and the others called the "sub"
channels. But there is no difference in how each channel is
transmitted over the multiplex. Here in New Zealand (DVB-T), we have
several multiplexes that broadcast "main" channels from multiple
different companies, as well as two multiplexes that work similarly to
the US model.
As for your padding question, the usual thing that happens when you
have more tuners available is that there is no need for back-to-back
recordings to take place on the same multirec tuner. So if the
recordings that used to have to be back-to-back are now recorded on
two different multirec tuners, the RecordPreRoll and RecordOverTime
settings that used to be ignored will now be applied, and you will get
60 seconds of preroll and 60 seconds of postroll (or whatever you have
those set to). Where there are not enough multirec tuners available,
the scheduler will have to do back-to-back recordings on the same
multirec tuner and will not apply those settings between the two
recordings, although the RecordPreRoll will be applied to the start of
the first recording and RecordOverTime will be applied at the end of
the last recording. If this is not how you want it to work, you can
adjust those two settings to 0 so that the only pre- and postroll that
happens will be from the recording rules.
Since you are saying that you do not have any pre- or postroll
settings at all, then the above is not an explanation, although I
would suggest that you check the settings again just to be sure there
are none on the affected recordings. However, there is one other
thing that mythbackend does that might explain it. Tuners take a
little while to be started up. That timing varies between tuners, and
also between multiplexes and channels within a multiplex. So
mythbackend starts a tuner up a bit earlier than it is needed, I think
about 60 seconds early, so that it will be ready when the time for the
recording to start comes along. I think it actually starts the
recording as soon as the tuning process completes, rather than waiting
until the exact moment that it is scheduled to start recording. So
you can get somewhere between 60 and 0 seconds of preroll from that.
There is no corresponding late stopping - recordings get stopped when
they are scheduled to be stopped, taking into account all the postroll
It would be unusual for your RecordPreRoll and RecordOverTime settings
to be 0 unless you have set them to be that at some time in the past.
There are good reasons for them to be defaulted to 60 seconds each. It
is possible that a MythTV upgrade has changed those settings, so it
would pay to check them. The mythbackend code has default values for
settings that it uses when there are no values in the database for
those settings. So if those defaults were 0 and a MythTV upgrade
added settings for RecordPreRoll and RecordOverTime to the database,
that could have changed how things work.
More information about the mythtv-users