[mythtv] dvb zero length record

[John Pullan]

On 23/05/05, Tom Hughes <tom at compton.nu> wrote:
> In message <7EF2F2C5-3D31-4F20-8D4E-F8F00A1DFCAD at cse.unsw.edu.au>
>           William Uther <willu.mailingLists at cse.unsw.edu.au> wrote:
> 
> > On Fri, 20 May 2005 09:01:32 +0100, Tom Hughes <tom at compton.nu> wrote:
> >
> > > None of those sounds like my case which was reported in the other
> > > thread that somebody referred you to. Those look like this:
> >
> > [snip]
> >
> > > 2005-05-09 13:38:10.289 DVB#0 Recorder: Card opened successfully
> > > (using PS mode).
> >
> > [snip]
> >
> > > I believe I now understand what is causing those ones, and I've been
> > > running with a fix since last Sunday and haven't lost anything yet. I
> > > was only loosing one or two a week though so I want to run it for
> > > another week or two before pronouncing it fixed for sure.
> >
> > Do you know if your fix is PS/TS specific?
> 
> It shouldn't be specific to either mode - the problem is in
> tuning the card to the right channel. How the data is read once
> tuning is complete is irrelevant.
> 
> > I'd be happy to help test that for you (in TS mode) if you want to
> > post a patch...
> 
> The basic problem is that sometime betwen 2.6.8 and 2.6.11 the
> way in which tuning is handled for DVB cards changed.
> 
> It used to be that when the FE_SET_FRONTEND ioctl was called the
> tuning was done by the frontend driver for the card you were using
> which (at least for the TwinHan DST cards I use) changed channel
> synchronously and didn't return from the ioctl until it had either
> retuned or had failed to tune.
> 
> So when Myth then did an FE_READ_STATUS to check for the FE_HAS_LOCK
> flag a lock would mean that the card had successfully tuned to the
> new channel.
> 
> What happens now is that the generic part of the DVB code does the
> tuning using a kernel thread which will potentially supply several
> different sets of tuning parameters to the frontend driver if some
> of the fields were left at auto in the FE_SET_FRONTEND call.
> 
> What this means is that tuning now happens in the background, but
> because FE_READ_STATUS interrogates the frontend directly it can
> see a lock for the old channel if the kernel thread hasn't started
> tuning yet. Myth may then read a PMT from that multiplex and fail
> to find the service it is looking for.
> 
> The fix I am using is to use FE_GET_EVENT instead which gets events
> from the background kernel thread so only reports a lock when tuning
> is really complete. So far it seems to be working.
> 
> If FE_GET_EVENT fails with EOPNOTSUPP due to running on an older
> kernel then my patch falls back to FE_READ_STATUS instead.
> 
> The patch is attached if you want to try it.
> 
> Tom
> 
Tom, I've just noticed on the linux-dvb list that a fix has gone in
for this situation. Might be worth you updating your drivers ?


-- 
John