Multi Record (TuningSignalCheck: SignalMonitor failed) ----- Wrong timeout

[jksj461]

I have recently resurrected a USB tuner (Hauppauge Dual HD) which performs very well. My previous use was with a maximum of 2 simultaneous recordings on each mux. Which worked.

I re-installed it with default parameters.
Signal timeout 3000
Tuning timeout 6000
Schedule as group enabled.

The card works very well with 0 continuity error counts and during testing I cannot break it by multirecording, 5 simultaneous on same mux.
However in normal use I periodically get SignalMonitor failed after 1 second of the recording start. I note that the period does not match the values set as above.

The fault occurs on a multi record of 2 or 3 programs after a period during which no recordings have been made.
The failure occurs on only 1 of the programs in the multirecord the others being perfect.
The following multi record always works no matter how many programs are involved, so the issue I guess is caused by a transient timing issue instigated by the first use of multirecord.

Single recordings never fail.
Multi recordings following this fail always work.

The history of incidences.
Sep 28 20:00:01 tv mythbackend: mythbackend[1523]: E TVRecEvent tv_rec.cpp:3959 (TuningSignalCheck) TVRec[9]: TuningSignalCheck: SignalMonitor failed
Sep 30 20:00:01 tv mythbackend: mythbackend[1525]: E TVRecEvent tv_rec.cpp:3959 (TuningSignalCheck) TVRec[9]: TuningSignalCheck: SignalMonitor failed
Sep 19 20:00:01 tv mythbackend: mythbackend[4247]: E TVRecEvent tv_rec.cpp:3959 (TuningSignalCheck) TVRec[9]: TuningSignalCheck: SignalMonitor failed
Sep 12 20:00:01 tv mythbackend: mythbackend[1854]: E TVRecEvent tv_rec.cpp:3959 (TuningSignalCheck) TVRec[9]: TuningSignalCheck: SignalMonitor failed
Note the time is the same for all the above, it is the first multirecord after startup as explained above.
The fact that it is always virtual tuner [9] may be relevant.

Log attached
debug.log

[Jpilk]

It might be worth noting that Channel 4 has had technical issues this week:

https://www.theguardian.com/media/2021/sep/25/channel-4-goes-off-air-after-outage-caused-by-technical-problem

[jksj461]

Yes thanks for the response. The Channel 4 outage was on the 24th and even then you got a signal with a blank screen. This incidence has the same footprint as the previous ones which relate to BBC Two so should still be a valid case.
I have two of these sticks and the newer one
Hauppauge model 204209, rev C2I6, serial# 14159259
seems to induce this issue quicker than the older one
Hauppauge model 204109, rev B3I6, serial# 14039842
Although the incidence rate is not high enough to be sure of this
So it does look like a marginal timing issue.
Which brings me back to why is the timeout 0.1 secs rather than the 0.3 specified in setup.
Or does the arrival of data on any PID trigger the check on all?

[kmdewaal]

It would be interesting to narrow this down a bit.
To summarize the problem:

• five recordings are scheduled on one multiplex
• all recordings are scheduled to start at exactly the same time
• system has to be idle / not recording for one hour before the recordings start
• then there is one bad recording

Question is then:

• what happens when another start time is selected, e.g. 21:00 instead of 20:00 (everything else the same)
• what happens when another type of tuner is used (same channels)
• what happens when this is done on another multiplex (same tuner)
• what happens when a similar test is done on e.g. satellite (also with five channels)
• what happens when four or three recordings are scheduled instead of five (same tuner)

Also, exactly which collection of channels is used? This might make it easy for other people to reproduce the problem.

I can think of things going wrong in MythTV but that should then go wrong every time and not require an hour wait time between tries. For example, IIRC there is a limit of 64 PIDs for all multirec programs together on one multiplex for DVB tuners. This number used to be not easily reached but with the MHEG/HBBTV there are lots of additional PIDs per program and it is feasible that the grand total exceeds 64. For SatIP the limit is 32 PIDs but when more than 32 PIDs are needed the the complete transport stream is selected.

It is possible to select Recording Profiles/ / Recording Type "TV Only" (instead of "Normal") and then the MHEG/HBBTV PIDs are skipped.
Only the BBC channels have MHEG so if this is the reason then the problem should be only on this mulitplex.
However, as described here it should not depend on the system being idle before the problem happens.

In general, USB devices can be sensitive to the port they are plugged in. Not all USB ports are created equal so try another. Also sometimes the power is an issue and then using a powered USB hub can make a difference.