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

[Ralph Metzler <rjkm@convergence.de>]

Matthias Weingart writes:
 > 
 > 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?

Well, such a "close" function is already available. It is called "close()".
Closing the file will always close the filter ...

I could change the behavior of the filters so that they already free their
resources when they are stopped. (Several people already proposed this to
me). his would only brake applications which rely on filters being
available once they were opened. If I change the driver as described
above it could happen that an open but stopped filter cannot be
started again but if you prefer it this way I'll do it.


Ralph



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