[mythtv-commits] [MythTV/mythtv] c4a1d5: Multirec with DVB CAM on encrypted channels

[kmdewaal]

  Branch: refs/heads/master
  Home:   https://github.com/MythTV/mythtv
  Commit: c4a1d5314b72116885f168bf28ebebaff775e825
      https://github.com/MythTV/mythtv/commit/c4a1d5314b72116885f168bf28ebebaff775e825
  Author: Klaas de Waal <kdewaal at mythtv.org>
  Date:   2019-07-13 (Sat, 13 Jul 2019)

  Changed paths:
    M mythtv/libs/libmythtv/recorders/streamhandler.cpp
    M mythtv/libs/libmythtv/recorders/streamhandler.h

  Log Message:
  -----------
  Multirec with DVB CAM on encrypted channels

Creating recordings of more than one channel of the same multiplex
with only one tuner, called multirec, has been implemented already
a long time ago. This works OK for non-encrypted (FTA) channels.

However, multirec has never worked reliably for encrypted channels
received with a card that has a CAM and a smartcard for decryption.
This is not a limitation of the CAM or the smartcard; recordings
that are started at different times are always good, but when
recordings start exactly the same moment sometimes one of them fails.
This happens when the backend is running and multiple recordings
are scheduled to start at the same time, or when the backend is
started when multiple recordings should have been running.

This is cause by the following.
- Each recording uses a StreamHandler
- The StreamHandler uses a DeviceRingBuffer when buffering is needed
- There is only one StreamHandler per physical tuner; additional
  recordings of that tuner share the same StreamHandler
- Starting a recording in MythTV is a two-stage process; first
  the StreamHandler is started without buffering; when
  that succeeds the StreamHandler is started again with buffering
- When two recordings start at the same time, and StreamHandler
  is shared, it can happen that a StreamHandler is shared
  when it does not do buffering but that buffering is required.
- In that case the StreamHandler is restarted. There is a log
  message "Restarting StreamHandler" when this happens.
- When the StreamHandler is restarted there is a short time
  when the StreamHandler is not running. This is typically
  5 to 10 milliseconds, as measured on my system.
- In the DVBSignalMonitor::UpdateValues() the function
  StreamHandler::IsRunning() is called to check if the
  StreamHandler is still running.
- If this happens exactly in the interval when the
  StreamHandler is restarted then the DVBSignalMonitor
  decides that the StreamHandler is NOT running and
  the error state m_error is set to "Error: stream handler died".
- TVRec::TuningSignalCheck checks SignalMonitor::IsErrored()
  and when that is true the recording fails.

The solution for this is to consider the StreamHandler
to be running while it is being restarted.

A possible reason why this problem happens on encrypted channels
and not on non-encrypted channels is that the tuning the first
channel takes much longer than tuning the second channel.
The second channel needs the buffering while the StreamHandler
is still in the non-buffering state needed by the first channel.

Note that there is still the possibility that this bug might also
have incidentally caused failed recordings on non-encrypted channels
because the "Restarting StreamHandler" messages have incidentally
been observed on non-encrypted channels.