Jukka Tastula wrote: > On Monday 20 June 2005 03:14, Manu Abraham wrote: >>Tell me, how often do you see the "bailout from previous error" >>message.. ? Does this hinder the speed of your zap/scan ? > > Every ten minutes or something, not very often but it happens. > I didn't test scanning at all, I just used vdr with the channels.conf I > already had and the messages show up while watching something. I have no > idea of course what vdr is doing in the background. > VDR does lot of tuning in the background i believe... Actually the i2c communication error is rated at 10 ~ 12 ppm.. ie 10 ~ 12 errors can happen in a million communication .. In our case due to our architecture problems we are forced to use the bttv style of communication.. This has caused an increased level of errors.. Earlier i tried my hand at this, but since there was no co-operation on this, i was forced to put a stop on it at that time.. I will surely revisit this very same issue.. > I set the cards up so that vdr always uses the same card for the same > frequency so there's no need to tune every time I change from a frequency > to another. > >>How often does this messages appear for you ? During a scan or a szap .. >>? I presume it is during a scan only.. > > Just running tzap and keeping it going will trigger the message. The rate > seems somewhat random, sometimes there are 20 in a minute and sometimes > none. Not too many all together though. > 20 messages a minute means, 20 times i2c communication was lost in a minute with the card.. This could have happened probably because of excessive communication on the i2c bus.. I was looking at to cut that down.. I thought i had shot down this monster.. I believe one more round of work is required with bttv.. >>To cross-verify it, i had a posted a set of patches a while earlier >>today .. The last patch logically reduces the chance for that error. >>Can you try that out too.. ? But you would require the entire set of > > With these patches I now have another new message. Tzapping to a channel > gives me a lock nicely and as fast as ever but the numbers seem a bit off > Nice to know that .. The previous FE_HAS_LOCK (based upon dst_get_signal() ) was bogus and highly error prone... Did not even require an another command for that ... ;-) That speeded up things .. > status 1f | signal 5400 | snr 5f00 | ber bfb05c80 | unc b7e8a28a | > FE_HAS_LOCK > > also while this is running dmesg is _filled_ (as in 200 messages in a > minute) with > > dst_get_signal: Getting Signal strength and other parameters !!!!!!!! > I put this message, just for debugging since i removed get_signal_strength() while tuning .. which caused so much communication that resulted in i2c errors.. Now the get_signal_strength() is called upon a szap only .. So VDR keeps zapping all the time.. (Hmm, i believe to workaround a loss of signal/lock) > Same happens if I use the femon plugin in vdr. > Yes, femon calls get_signal(), which calls dst_get_signal() That one is spewing out the messages.. > With these patches I don't seem to be able to get the other messages > anymore unless I run dvbscan. And yes you are right, there are more of the > error messages when dvbscan attempts an invalid frequency. > So, my logic was correct in my post on the other thread, that a get_signal_strength() should not be done while doing a scan.. And yes, results in 50% lesser i2c communication.. as well makes the MCU a bit free also .. Technically speaking results in a faster scan.. You can see the difference when you disable the printk's in both the cases.. printk's are considered to be quite some time consuming .. But they are there for a good reason to assist in debugging, when you think all is lost .. But once you have this problem fixed.. we can turn this into an option, but at that point that also doesn't make sense since the message will not be seen .. :-) >>Now is it specific to your card, you are seeing this error too often, or >>everyone is seeing this too often.. The reason why i ask is, on all my 4 >>variants, it happens in the case when trying to tune to a non-existant >>frequency/polarity.. >> >>Is it the same case with you ? > > With the vanilla cvs the messages just keep coming, it doesn't seem to > matter what I tune to or with. > Yes, that substantiates my previous point .. Since these changes have not gone into CVS.. >>Would it be better if i just ignore these errors ? And make it dependant >>upon the debug module parameter ? > > So far I haven't noticed any ill effects from whatever is causing the > messages to appear but I really haven't tested it very much; spent the > whole day reinstalling the system after a broken memory module trashed the > root fs. > Yep, i faced situations like the HDD suddenly lost it's mind and had to fall back to an older backed up version.. Can be really irritating .. >>One question that i forgot to ask you is which card do you have ? I mean >>model number and device_id .. > > I have no idea what the model number is. The package says chaintech > dtt-1000 but beyond that I really have no clue at all. > Hmm .. yeah it is very difficult to identify the exact model with a clone .. Johannes also has the same card i believe.. > Linux video capture interface: v1.00 > bttv: driver version 0.9.15 loaded > bttv: using 8 buffers with 2080k (520 pages) each for capture > bttv: Bt8xx card found (0). > ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 16 > bttv0: Bt878 (rev 17) at 0000:00:08.0, irq: 16, latency: 32, mmio: > 0xe8111000 > bttv0: detected: ChainTech digitop DST-1000 DVB-S [card=113], PCI subsystem This is from bttv.. I had posted a mail to Gerd sometime back on this stating that it is a simple DVB card .. Maybe Gerd forgot or did not want to have it in .. > ID is 270f:fc00 > bttv0: using: Twinhan DST + clones [card=113,autodetected] > bttv0: using tuner=4 > bttv0: add subdevice "dvb0" > bt878: Bt878 AUDIO function found (0). > ACPI: PCI Interrupt 0000:00:08.1[A] -> GSI 16 (level, low) -> IRQ 16 > bt878(0): Bt878 (rev 17) at 00:08.1, irq: 16, latency: 32, memory: > 0xe8114000 > DVB: registering new adapter (bttv0). > dst_get_device_id: Recognise [DTTDIG] > DST type : terrestrial > DST type flags : 0x10 firmware version = 2 > DVB: registering frontend 0 (DST DVB-T)... > > It just likes to say it's DVB-S but it's really a DVB-T card. Yep... bttv would like to have it that way i think... Where does it say other than that.. I believe not .. All Twinhan cards and clones share the same PCIID, so whichever card that might be it is a DVB card rater than DVB-S/C/T.. A while back bttv had every Twinhan & clone as DVB-T Manu
