Peter Beutner wrote: > Johannes Stezenbach schrieb: > >On Sat, Jun 04, 2005 at 09:48:13PM +0200, Peter Beutner wrote: > >>Prevent this by automatically returning zero if frontend state is > >>FE_RETUNE. > > > >Hm, nice catch. Did you actually manage to hit this race? > yes, I ccasionally saw it when using tzap. The first line reports a > HAS_LOCK, while the second(and sometimes third) shows no signal lock and > next one finally has the lock again. OK, I comitted this part of your patch (two unrelated fixes shouldn't be comitted togther anyway). Thanks! > >>In dvb_dmxdev_filter_start if we go out because of an error, release > >>previously allocated demux_feed. > > > >This is a bit subtle. The feed is released in dvb_demux_release() (when > >the device is closed). What was the problem you were trying to fix with > >this patch? > The problem is if you change the pid filter without closing the demux > device. For example when changing the channel. Consider the following > sequence: > tune(); > ioctl(DMX_SET_PES_FILTER); > ioctl(DMX_START); > ... > ioctl(DMX_STOP); > tune(); > ioctl(DMX_SET_PES_FILTER); > ioctl(DMX_START); > ... > (xine does it this way for example) > > As the status of the filter isn't set to DMXDEV_STATE_GO if an error > occurs in dvb_dmx_filter_start, it wont be released in > dvb_dmx_filter_stop. Because the number of filters is limited, it will > run out of filters after zapping through a few channels Hm, it looks like you are right. The code is just too confusing :-( E.g dmx_ts_feed_set() calls dvb_demux_feed_add(), but since theres no such thing as dmx_ts_feed_unset(), the corresponding call to dvb_demux_feed_del() is part of dvbdmx_release_ts_feed(). What drivers dod you test this with? > Btw just ~5 lines above the one i changed with the patch, there is > exactly the same situation. And there it is done the way as the patch > does it. Two questions: - why does ->start_filtering() fail? - does the same bug exist for the section filters? Johannes
