On Tue, Jun 28, 2005 at 09:31:25PM +0000, Stefan Seyfried wrote: > On Sun, Jun 19, 2005 at 05:56:29PM +0000, Stefan Seyfried wrote: > > > i just tried to reproduce it this way and wasn't able to reproduce; It seems > > to happen only when using dvbd to tune in. > > This one reproduces it easily: > > -------------------------------- > > #!/bin/bash > > TYPE=dvb-s > > > > for CHAN in 'Das Erste' ZDF 'RTL Television' EinsPlus SAT.1 'WDR Essen'; do > > echo "$CHAN" > > dvbcat -o /dev/null -d 5 $TYPE "$CHAN" & > > PID=$! > > tv_grab_dvb > /dev/null > > kill $PID; sleep 2 > > done > > -------------------------------- > > > I would have bet i have seen it with tzap on the cinergyT2, but i can only > > verify this tomorrow when i am back in dvb-t-land. > > seems like i had some hallucinations :-) The cinergyT2 behaves exactly like > the budget-ci: tzap does not expose the memory leak but dvbd does. It does not > matter if i grab the EPG with tv_grab_dvb or with "dvbrowse -p", after tuning > to all 6 transponders here in Nuernberg with dvbcat/dvbd, i have 10MB less > free memory. I have found out what the difference between tzap and dvbd is WRT tuning: dvbd keeps the frontend (and demux?) FDs open for 5 seconds after its last client exited, so the flow of events is: open FDs tune channel, start dvr stop dvr, tune channel start dvr stop dvr, tune channel start dvr .... close FDs while with tzap it is: open FDs tune channel, start dvr stop dvr close FDs repeat ;-) If e.g. dvbrowse -p is running in the background, i lose about 1.5MB of kernel memory with the first method, none with the second. I have modified dvbd to close the filedescriptors immediately after the last client exited, but this is merely a workaround for this driver bug. Should i file a bug at bugzilla.kernel.org or is reporting this here enough? -- Stefan Seyfried
