[mythtv-commits] [MythTV/mythtv] 62781a: Start Live TV on first available tuner

kmdewaal noreply at github.com
Fri Jan 28 21:37:06 UTC 2022


  Branch: refs/heads/master
  Home:   https://github.com/MythTV/mythtv
  Commit: 62781aad12ebb08fd53eeff27b13a1edbc9b5e3e
      https://github.com/MythTV/mythtv/commit/62781aad12ebb08fd53eeff27b13a1edbc9b5e3e
  Author: Klaas de Waal <klaas at kldo.nl>
  Date:   2022-01-28 (Fri, 28 Jan 2022)

  Changed paths:
    M mythtv/libs/libmythtv/tv_play.cpp
    M mythtv/libs/libmythtv/tv_play.h

  Log Message:
  -----------
  Start Live TV on first available tuner

When a program is selected for Live TV then a tuner is selected that is capable of
receiving this program. When there are also virtual tuners configured on the selected
physical tuner then both the physical tuner and the virtual tuners are all capable of
receiving the selected program.
The tuner to be used is one from a list of available tuners, including both the physical
and the virtual tuners. Often the physical tuner is selected, but not always.
The reason for this is that the list of available tuners is stored in a QSet and the
elements in a QSet do not have a defined order.

This commit changes the QSet to a QVector and all tuners found are now added to
the end of the vector. The selected tuner is now always the first element of the vector.
When the tuner is not yet in use then the tuner selected for live tv is the physical
tuner because this is the first one found. Note that this is not necessarily so but
this is because mythtv-setup fills the database table capturecard in this way.

Avoiding unwanted non-deterministic behavior is a goal in itself, if only because
it makes trouble shooting easier.
However, in this case this fix does solve a problem with EIT.
What happens is the following:
- Active EIT is using the physical tuner. This is only done when the tuner is available.
- All tuners, the phsyical and the virtual, are marked available.
- When a recording is started on a virtual tuner then the EIT on the physical tuner keeps on running.
- The recording on the virtual tuner causes a tuning of the physical tuner so it will receive a different stream.
- This then causes EIT processing to be continue on a different stream.
It is quite amazing that this does actually work without giving big problems.
The main indication that something is wrong is an endless stream of these error messages:
2021-12-01 09:18:22.826074 I  DTVSigMon[3]: HandlePAT() Received PAT for tsid 2055 waiting for tsid 2073
2021-12-01 09:18:22.897088 I  DTVSigMon[3]: HandlePAT() Received PAT for tsid 2055 waiting for tsid 2073
2021-12-01 09:18:22.977255 I  DTVSigMon[3]: HandlePAT() Received PAT for tsid 2055 waiting for tsid 2073
one for each time a PAT is received from the new stream while still expecting a PAT from the old stream.
Curiosity about the cause for these error messages was the reason to start this investigation.

The way EIT works is as follows:
- When the physical tuner is free then this tuner is used for EIT collection; this is active EIT.
- When the physical tuner is used for recording, either Live TV or only to disk, then EIT is
  collected from the transport stream that the tuner is tuned on; this is passive EIT.
- There is no EIT collected from recordings on virtual tuners, not active and not passive.
This makes it desirable to avoid a situation where virtual tuners are used and physical tuners are idle.

The following can be remarked:
- It could be better to do explicit sorting to insure that the physical tuners come first instead of relying on
  the order of the EncoderList, which is essentiallly how it is stored in database table capturecard.
- Stop active EIT on the idle physical tuner when a recording is started on a virtual tuner.
  This is possible and even desirable, but not trivial. Also, EIT collection stops in this situation.
- Do passive EIT also when recording from virtual tuners. This gives duplicate EIT events but these
  will be filtered out by the EIT cache processing so the performance impact is probably minimal.
EIT processing is being looked at for other issues as well so keep watching the commit mailing list.




More information about the mythtv-commits mailing list