[linux-dvb] Re: Tuning with driver 2001-05-28

[Matthias Weingart <matthias@pentax.boerde.de>]

On Tue, 5 Jun 2001, Johannes Stezenbach wrote:

> Klaus Schmidinger wrote:
> > 
> > I have been running a lot of tuning tests and found that there is
> > one channel that most of the time doesn't get tuned to correctly:
> > 
> > CNN:12168:v:0:27500:165:100:0:0:28512
> > 
> > (that's in VDR's channels.conf notation).
> > 
> > Could there be a problem in the tuning mechanism of the driver?
> > When trying to tune to this channel I sometimes get the error code
> > for "Device or resource busy" whe trying to set the PIDs.
> 
> Well, there is a catch associated with setting the PIDs:
> Assuming channel A has video/audio PIDs 100/101, and channel
> B has PIDs 101/102 (on a different transponder, obviously).
> Then when switching from A to B you will get "device or resource
> busy" when trying to set the video PID because the old audio PID
> is still active (the demux hardware allows only one PES filter per PID).
> 
> If the driver is loaded with pids_off=0 (default in the Makefile
> from the CVS distribution), DMX_STOP and/or closing the demux file
> descriptor will *not* free the hardware filter.
> (pids_off=0 is meant to be used with tuxzap/tuxview, so you can
> continue to watch with tuxview after you have quit tuxzap.)
> 
> OTOH, when you try to set a PID filter and it fails, the hardware
> filter formerly associated with this demux file descriptor will be freed.
> 
> Solution: If one of the DMX_SET_PES_FILTER ioctls returned EBUSY,
> retry them all (i.e. set A/V/TT, and when one failed, set A/V/TT again).
> If you have set a teletext PID for some channel, and then tune to a
> channel w/o teletext PID, reset the teletext PID to 0x1fff (which will
> generate an error, but the hardware filter will be freed).
> If you tune to a radio channel, be shure to reset the video PID to
> 0x1fff, too.

This is a very crazy behaviour of the driver, really. This "trial and
error and retry" is not pulchritudinous.
 Another solution is to compile the driver with pids_off=1, right? I think
vdr (or the user) should do it this way. But I foretell you that this will
be the most ask question in this list in the future. ;-/ 
 Another acceptable way would be to call a function of the driver to
explicitly close the PID filters, independent of pids_off=0 (tuxzap should
never call this function). Can you insert such a function into the driver?
Why such nasty workaround, when we can do it better?

        Matthias




-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.