[mythtv-users] Recording problems after upgrade to 0.28

[John Pilkington]

On 27/07/16 09:06, Stephen Worthington wrote:
> On Tue, 26 Jul 2016 19:14:13 +0100, you wrote:
>
>> On 26/07/16 15:35, Peter Bennett wrote:
>>> On 07/26/2016 08:25 AM, Stephen Worthington wrote:
>>>> Also, is the default 3000 ms value for the DVB-T tuning time possibly
>>>> too small?  Or is it just that the NZ TV3 channel is doing something
>>>> unusual that is causing it to need a longer tuning time?
>>> I am not in New Zealand.
>>>
>>> I had similar problems after upgrade to 0.28 and I changed all of my
>>> tuning timeouts to 5000. It seems that 0.28 has different checking for
>>> failed recordings and marks the recording as failed after a tuning
>>> timeout, even though it recorded perfectly.
>>>
>>> Peter
>>
>> I also found 0.28 is more sensitive with DVB-T/T2, I changed signal
>> timeout to 7000 and tuning timeout to 10000 for all my DVB-T/T2 devices
>> (same as used for DVB-S/S2) and have not  had a problem since (I did
>> this many months ago when I was running 0.28pre).
>
> I have changed my tuning timeout to 10000 ms and so far all the
> symptoms I was seeing have disappeared.  I have not changed the signal
> timeout at all.  It is a little early yet to say the problem is
> completely cured, but it is very promising as my box has made it
> through today's peak recording period with a similar number of
> recordings happening as did yesterday, but no problems occurred.
>
> It is encouraging that others have had similar problems and had them
> solved by increasing the tuning timeout.
>
> Clearly the 3000 ms tuning timeout is wrong for DVB-T tuners, at least
> in this part of the world and since the 0.28 changes.  So I think that
> default value needs changing to a much larger number.  Looking back at
> my 0.27 logs, I can see that TV3 had tuning problems then too, it is
> just that they were not particularly visible.  The 0.28 changes have
> made them very visible, but 0.27 looks like it needed a larger tuning
> timeout too.

There was a thread last October 'Odd behaviour after recording failed' 
that touched on some of this.  I hadn't found a legit way of unsetting 
the failed flag if inspection showed that the recording was good.  I 
guess since then I just stopped worrying :-)