[mythtv-users] Scheduled recording failed at start didn't retry

Michael T. Dean mtdean at thirdcontact.com
Tue Feb 19 13:31:41 UTC 2019

On 02/19/2019 08:07 AM, James Abernathy wrote:
> I'm on the latest V30 (2:30.0+fixes.201902171942.70a58c0~ubuntu18.04.1)
> I had a program scheduled for 7am and when I checked at ~ 7:30 I 
> expected it to be displayed in the list of recordings in Green because 
> it was in process of recording.  It was displayed in normal text 
> (white on black) and very small.  When I clicked on the program it 
> couldn't find the file.  So I deleted the entry and restarted the 
> recording. Seems okay now, but weird.
> I have the journalctl output liked below.
> http://paste.ubuntu.com/p/nnByh5D5HZ/

> Feb 19 07:00:03 mythbuntu mythbackend[2426]: mythbackend[2426]: E TVRecEvent tv_rec.cpp:3989 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: Hit pre-fail timeout
> Feb 19 07:00:04 mythbuntu mythbackend[2426]: mythbackend[2426]: W TVRecEvent tv_rec.cpp:4020 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: taking more than 3000 ms to get a lock. marking this recording as 'Failing'.
> Feb 19 07:00:04 mythbuntu mythbackend[2426]: mythbackend[2426]: W TVRecEvent tv_rec.cpp:4022 (TuningSignalCheck) TVRec[1]: See 'Tuning timeout' in mythtv-setup for this input

Your tuner failed to tune the channel before the timeout.  You need to 
increase the tuning (and, probably, signal) timeouts for your tuner(s) 
in mythtv-setup.  The defaults tend to be rather aggressive and only 
tend to work in the best of circumstances, so most people should 
increase them.  Even though the channel tuned successfully at a later 
time, because it failed to tune at the appropriate time, your timeouts 
are too low--they're too low to succeed in all conditions you will 
encounter (i.e. because signal strength varies or whatever).

For recordings, having a huge timeout (i.e. instead of a default 
3000/1000ms, having more like 10000/10000ms) makes no difference on 
performance since no one is waiting on the tuner. The main reason for 
the aggressive defaults is because there's a huge impact for initial 
scanning--having to wait 10-20s per channel to find out there's no 
channel there when doing a channel scan of 70+ channels is incredibly 
slow. On Live TV, there's no impact to a huge timeout if tuning should 
work (i.e. if the channel actually exists and is properly set up in the 
database).  The only time the huge timeout will slow things for Live TV 
is if there's a failure to tune--which will mean waiting the entire 
timeout to get a failure message and be able to do whatever you're going 
to do about it.  So, I highly recommend just setting them both to 10s 
(10000ms) once you've got your system set up.

And, FWIW, if MythTV is unable to tune the channel/start the recording, 
it will not try again.  If there was a problem when the recording was 
meant to start, we assume that it's a systemic problem and may or may 
not require user intervention, so we don't keep trying the same thing 
and expecting a different result.  In this case, the user intervention 
required is increasing the timeouts.


More information about the mythtv-users mailing list