[mythtv] Failed DVB recording

[Tom Hughes]

In message <1112895308.42556f4cb9d20 at www.digitalregime.com>
          Taylor Jacob <rtjacob at earthlink.net> wrote:

> Quoting Tom Hughes <tom at compton.nu>:
> 
> <massive snip>
> 
> > 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.
> 
> In regards to all of this it could be one of 2 things:
> 
> 1. Drivers not properly opening section filtering for the PMT PID requested..
> 2. Myth not doing cleanup when closing Section Filters..
> 
> I have NEVER seen this with my cards (Happauge Nova/Nexus, Skystar2,
> Air2PC, and (briefly used so far) pcHDTV2k)..

I've just had it happen again with the longer timeout, so I think we
can rule that out. I also had siparser debugging on this time and I have
an interesting log:

2005-04-14 18:30:03.248 SIParser: About to do a reset
2005-04-14 18:30:03.250 SIParser: Closing all PIDs
2005-04-14 18:30:03.260 SIParser: Resetting all Table Handlers
2005-04-14 18:30:03.279 SIParser: SIParser Reset due to channel change
2005-04-14 18:30:03.797 Reschedule requested for id 0.
2005-04-14 18:30:04.511 Scheduled 186 items in 0.7 = 0.00 match + 0.71 place
2005-04-14 18:30:04.527 scheduler: Scheduled items
2005-04-14 18:30:04.914 DVB#0 DVB signal 4b00 | snr 5000 | ber 776df12 | unc 4911d28
2005-04-14 18:30:04.915 DVB#0 Status: LOCK.
2005-04-14 18:30:04.916 SIParser: Requesting PAT
2005-04-14 18:30:04.918 DVB#0 Multiplex Locked
2005-04-14 18:30:04.926 SIParser: Adding a PMT (8384) to the request list
2005-04-14 18:30:05.265 SIParser: Table[0]->RequirePIDs() == true
2005-04-14 18:30:05.267 SIParser: Adding PID    0 Filter  0 Mask ff Buffer 40960
2005-04-14 18:30:05.268 SIParser: Table[2]->RequirePIDs() == true
2005-04-14 18:30:05.269 SIParser: Adding PID 1ffb Filter ff Mask  0 Buffer 40960
2005-04-14 18:30:05.270 SIParser: Table[3]->RequirePIDs() == true
2005-04-14 18:30:05.271 SIParser: Adding PID 1ffb Filter ff Mask  0 Buffer 40960
2005-04-14 18:30:05.272 SIParser: Table[6]->RequirePIDs() == true
2005-04-14 18:30:05.273 SIParser: Adding PID   10 Filter 40 Mask ff Buffer 40960
2005-04-14 18:30:05.277 SIParser: PAT Version = 25
2005-04-14 18:30:05.279 SIParser: Tuned to TransportID: 12290
2005-04-14 18:30:05.280 SIParser: NIT Present on this transport on PID 16
2005-04-14 18:30:05.282 SIParser: Services on this Transport: 12866 13120 14208 14272 14336 14400 14464 14528 14592 14656 14784 14848 14976 15040 15104 15168 15232 15488 15552 15616 15680 15744 15808
2005-04-14 18:30:05.283 SIParser: Table[0]->Complete() == true
2005-04-14 18:30:05.284 SIParser: Table[1]->RequirePIDs() == true
2005-04-14 18:30:05.295 SIParser: Adding PID    0 Filter  2 Mask ff Buffer 40960
2005-04-14 18:30:16.363 SIParser: Private Type channel_numbers = 131 defined for NetworkID 9018
QString::arg(): Argument missing: ChannelNumbers Present using Descriptor %d, 131
2005-04-14 18:30:16.371 SIParser: ChannelNumbers Present using Descriptor %d
2005-04-14 18:30:16.372 SIParser: Private Type guide_fixup = 2 defined for NetworkID 9018
2005-04-14 18:30:16.373 SIParser: Using Guide Fixup Scheme #2
2005-04-14 18:30:16.376 SIParser: Table[6]->Complete() == true
2005-04-14 18:30:16.393 SIParser: Table[5]->RequirePIDs() == true

The interesting thing is that is requests service 8384 which is on
transport 8197 but it appears to report that is has tuned the card
to transport 12290 and then gives the correct lists of services
for that transport which doesn't include the one it wanted.

Transport 12290 is in fact the transport that the card was tuned
to previously - it was changing recording from one channel to
another at the time.

Looking at the code I see that it asks the frontend to tune to the
new transport and then polls with another ioctl until a lock is
reported. I wonder if there is a race condition such that it can
sometimes get to the poll before the card starts retuning and hence
it reports a lock which is actually a lock for the previous tuning
parameters?

At the very least I guess it should check when the lock is reported
that it was on the expected transport.

Tom

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