[mythtv-users] Events at the beginning of a recording

[Klaas de Waal]

On Thu, 9 Feb 2023 at 13:15, Jan Ceuleers <jan.ceuleers at gmail.com> wrote:

> On 09/02/2023 12:33, John Pilkington wrote:
> >> Just to state my understanding of your point: I believe you refer to
> >> specifying pre and post-roll in recording rules, is that right? (Perhaps
> >> I'm not using the correct terminology here; apologies if so).
> >>
> >> If so, the reason why I am now using the global pre-roll feature is
> >> that, in my understanding, it enables back-to-back recordings on the
> >> same capture card, whereas with recording rule-specified pre/post-rolls
> >> two capture cards are needed to record back-to-back programs.
> >>
> > Maybe your more complex system has this problem, but I have no such
> > difficulty with my DVB-T/T2 tuners when using a default recording rule,
> > 2m early 4m late, with EIT data.  Most of my recordings are
> > single-record only, aand back-to-back happens often.
>
> Yes, a multirec-capable tuner (which most DVB-x tuners are) does not
> have this problem to the same extent, because they natively support the
> concept of multiplexes which MythTV's multirec capability was designed
> for. My HDHR DVB-C tuner, for example, also does not, in that it has
> multiple virtual tuners available that can be swung into service for the
> purpose of back-to-back recordings (or indeed for parallel recordings of
> any combination of channels on the same multiplex).
>
> But the encrypted channels my cable company provides need to be accessed
> by means of a set-top box, and there is presently no "multirec"
> capability for one-channel-at-a-time capture cards.
>
> Cheers, Jan
>
> I have just now created a pull request #716 (
https://github.com/MythTV/mythtv/pull/716) with a fix that does solve the
REC_PENDING event issue in my testing.

Klaas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230209/ff0e76c9/attachment.htm>