[mythtv] Failed DVB recording

[Tom Hughes]

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.
> >
> > Obviously it failed to tune the right channel due to a timeout
> > getting the PMT from the multiplex. I don't know what the cause
> > of that was, but what happened afterwards is that it continued
> > to pretend it was recording and spew out those "No data" messages
> > for the duration of the program.
> 
> Can you tune to this multiplex with zap and look at the PMT deltas?  There is
> currently a 5 second PMT timeout when attempting to get the PIDs for the
> desired channel.  The average PMT delta is .1 to .2 seconds, so I suspect that
> there was some issue with the deilvery of it.

How do you get the PMT deltas out of tzap? I can't see anything obvious
in the source, and all running it on that channel gets me is this:

hampton [~/src/linuxtv-dvb-apps] % ./tzap -c channels.conf "Channel 4"
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 481833330 Hz
video pid 0x0b2c, audio pid 0x0b2d
status 00 | signal 0000 | snr 0000 | ber 0083aa0e | unc 008194b3 |
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5500 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK
status 1f | signal 5300 | snr 6200 | ber 0083aa0e | unc 008194b3 | FE_HAS_LOCK

I actually had the same problem tonight. I restarted the backend
because I had upgraded it and both cards failed to tune on startup
and then wouldn't do anything else. They were trying tune two
different channels on two different multiplexes as well. Restarting
again fixed it.

This time however I have some idea what happened. The machine was
pretty busy doing other things when I restarted the backend so it
maybe that triggers a timeout?

Tom

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