On Sonntag 17 September 2006 22:40, Stefan Lucke wrote: > On Sonntag 17 September 2006 22:09, Patrick Boettcher wrote: > > Hi Stefan, > > > > On Sun, 17 Sep 2006, Stefan Lucke wrote: > > > On Samstag 16 September 2006 19:53, Stefan Lucke wrote: > > > > Hi, > > > > with my new skystar2 2.6D I've a problem when for some reason a reception from > > > > for example Pro7 (astra 19.2e) gets in trouble. Vdr reports: > > > > Sep 16 19:34:32 jarada jarada vdr: [14014] TS buffer on device 1 thread started (pid=13788, tid=14014) > > > > Sep 16 19:34:33 jarada jarada vdr: [13792] frontend 0 lost lock on channel 1017, tp 212480 > > > > Sep 16 19:34:33 jarada jarada vdr: [13792] frontend 0 regained lock on channel 1017, tp 212480 > > > > Sep 16 19:34:53 jarada jarada vdr: [13792] frontend 0 lost lock on channel 1017, tp 212480 > > > > Sep 16 19:34:53 jarada jarada vdr: [13792] frontend 0 regained lock on channel 1017, tp 212480 > > > > > > > > When this happens, it is impossible to tune to other channels like ARD, .. . > > > > Femon reports then for ARD: SNR 0xbfda 75% , BER = 0 > > > > > > > > Only restarting vdr resolves this issue. > > > > > > My problem is not the bad reception quality. At the moment roubles start, > > > I've a non zero BER values. > > > The problem is that other channels, which worked previously, now don't work anymore. > > > A search in the archive lead me to the thread: Air/SkyStar2 IRQ stop (partial) fix > > > > > > Is it possible that we/I have this problem again ? > > > > No. The IRQ stop problem has nothing to do with the reception it is simply > > a data transfer problem. > > As I said: the reception is not my problem. At the moment this happens I looked > at Pro7 (dect issue I know) and had a bad picture. Ffmpeg reported a lots of errors. > femon showed non zero BER. Then I switched to ARD and had zero BER. So I think > tuning to ARD was successful. Tuning back to Pro7 brings non zero BER again. > I could could toggle between them with same behavior of BER. > That makes me think of: the data transfer just did not start. > > One time it recovered. There was a vdr retune followed by a manual retune. Fast switching between channles seems to recover this more often. I did some traces. The trace log you'll find here: http://www.lucke.in-berlin.de/b2c2_log/ I inserted some comments which could be found by searching for "----" . When this condition is met: "if (fc->feedcount == onoff)" data transfer is recoverd. modprobe b2c2_flexcop debug=17 modprobe b2c2_flexcop_pci debug=17 I added 2 additional trace messages: diff -r 3e90edbf7c53 linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c --- a/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Thu Sep 14 18:41:13 2006 +++ b/linux/drivers/media/dvb/b2c2/flexcop-hw-filter.c Wed Sep 20 12:31:07 2006 @@ -178,6 +178,7 @@ } /* if it was the first or last feed request change the stream-status */ +deb_info("-- feedcount = %d %d\n",fc->feedcount,onoff); if (fc->feedcount == onoff) { flexcop_rcv_data_ctrl(fc,onoff); if (fc->stream_control) /* device specific stream control */ diff -r 3e90edbf7c53 linux/drivers/media/dvb/b2c2/flexcop.c --- a/linux/drivers/media/dvb/b2c2/flexcop.c Thu Sep 14 18:41:13 2006 +++ b/linux/drivers/media/dvb/b2c2/flexcop.c Wed Sep 20 12:31:07 2006 @@ -200,6 +200,7 @@ flexcop_ibi_value v208_save = fc->read_ibi_reg(fc,ctrl_208), v210 = fc->read_ibi_reg(fc,sw_reset_210); + deb_info("208: %08x, 210: %08x\n",v208_save.raw,v210.raw); deb_rdump("208: %08x, 210: %08x\n",v208_save.raw,v210.raw); fc->write_ibi_reg(fc,ctrl_208,ibi_zero); -- Stefan Lucke _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
