[mythtv] Failed DVB recording

[Tom Hughes]

In message <yek1x9nc92m.fsf at honda.uk.cyberscience.com>
        Tom Hughes <tom at compton.nu> wrote:

> In message <e558cc3b4d.tom at loxley.compton.nu>
>         Tom Hughes <tom at compton.nu> wrote:
>
>> In message <1108064943.420bbaaf3b10f at www.digitalregime.com>
>>           Taylor Jacob <rtjacob at earthlink.net> wrote:
>>
>>> Quoting Tom Hughes <tom at compton.nu>:
>>> 
>>> > I had a DVB recording fail last night. The relevant log extract is:
>>> 
>>> > 2005-02-09 18:30:04.271 DVB#0 DVB signal 5300 | snr 5000 | ber 143af12 | unc
>>> > 7961d18
>>> > 2005-02-09 18:30:04.273 DVB#0 Status: LOCK.
>>> > 2005-02-09 18:30:04.273 DVB#0 Multiplex Locked
>>> > 2005-02-09 18:30:10.966 DVB#0 Timeout Getting PMT
>>> > 2005-02-09 18:30:11.096 DVB#0 ERROR - Tuning for channel #4 failed.
>>> > 2005-02-09 18:30:11.176 Changing from None to RecordingOnly
>>> > 2005-02-09 18:30:11.237 DVB#0 Recorder: Card opened successfully (using PS
>>> > mode).
>>> > 2005-02-09 18:30:12.265 DVB#0 WARNING - No data from card in 1 second.
>>> > 2005-02-09 18:30:13.316 DVB#0 WARNING - No data from card in 1 second.
>>> > 2005-02-09 18:30:14.318 DVB#0 WARNING - No data from card in 1 second.

[ snipped ]

>> OK. I've worked out how to do this now by tuning with tzap and then
>> using dvbsnoop to look for the PMT data. They are coming in about
>> every 0.19 seconds most of the time - one or are longer but the longest
>> that I've seen is about 0.35 or so.
>
> I've had this happen a few more times recently so I decided to try
> increasing the timeout to see if it helped but I when I went to look
> at the code I found that the timeout is not actually 5 seconds but
> is just 0.3 seconds which would explain why I'm having problems as
> my gaps between PMTs are sometimes as long as 0.35 seconds.
>
> The code in DVBChannel::Tune does 3000 iterations of the loop and
> sleeps for 100us on each pass which gives 300000us or 0.3 seconds.

I'm a bit less sure about this now - if you look at the log it shows
a delay of around 6 seconds. I think the reason is that you can't
actually usleep for 500us - the minimum time you can sleep for will
be with 1/100 or 1/512 seconds depending on your kernel and processor.

So in my case I am sleeping for 3000 * 1/512 seconds, or 5.86 seconds.

I'll just have to see if increasing the iterations does help or if
there is a more fundamental problem.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/