[mythtv-users] TuningSignalCheck: SignalMonitor failed ----- Wrong timeout

John jksjdevelop at gmail.com
Wed Sep 29 16:36:26 UTC 2021

On 29/09/2021 13:17, Stephen Worthington wrote:
> On Wed, 29 Sep 2021 12:44:19 +0100, you wrote:
>> v32-Pre-2807-g8a7505a0ad
>> I have recently resurrected a USB tuner (Hauppauge Dual HD) which
>> performs very well. However it is failing every few days with the
>> following error:-
>> Three instances:-
>> Sep 28 20:00:01 tv mythbackend: mythbackend[1523]: 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
>> EIT scanning is running on this mux.
>> The fact that they all occur at the same time is pretty weird. The
>> backend boots up at 17:00 and does a couple of single recordings from
>> then until about 18:30. At 20:00 the main recording period starts. The
>> above failure is not fatal, later recordings on this mux do work.
>> The fact that the timeout is only one second is strange as well - the
>> timeouts for the tuner are the defaults 3000 signal 6000 tune.
>> Can anybody give any guidance on what logging is required to debug this
>> and I will raise it as a proper issue.
> Here in New Zealand, we have one DVB-T channel ("Three") which
> requires a much longer timeout for some reason.  So if the recordings
> that fail are all on one channel, that is a likely cause.  Three takes
> 7000-8000 ms to tune normally, and sometimes even longer, so I have
> set all my capturecard.channel_timeout values to 10000 ms and that
> fixed the problem.  I have only 1000 ms for capturecard.signal_timeout
> - I have never had any problem with that setting.
> I had to make that change to my settings after one MythTV version
> upgrade where the tuning was changed so that it does not automatically
> retry and instead obeyed the timeouts.  Before that change, tuning of
> Three worked, apparently by timing out and retrying on the same tuner,
> but without restarting the tuning process completely.  So the tuner
> got set to receive the mux containing Three and mythbackend started
> receiving data, but failed to find the header packets for the Three
> channel and timed out.  But it left the tuner running and restarted
> looking for the header packets, and then found them on the second try,
> before a second timeout happened.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

Thanks for the response it sounds like a reasonable theory but I can't 
understand why the backend is failing the recording after just one second.

Sep 28 20:00:01 tv mythbackend: mythbackend[1523]: I CoreContext 
scheduler.cpp:706 (UpdateRecStatus) Updating status for "The Great 
British Bake Off" on cardid [9] (Tuning => Recorder Failed)

More information about the mythtv-users mailing list