Am Samstag, 21. Juli 2007 15:57:12 schrieben Sie: > Le samedi 21 juillet 2007 00:30, Uwe Bugla a écrit : > > Am Freitag, 20. Juli 2007 15:03:55 schrieb Christophe Thommeret: > > > Le jeudi 19 juillet 2007 16:26, Uwe Bugla a écrit : > > > > > > > (The main difference between dvbscan and kaffeine is that > > > > > > > kaffeine filters one pid at a time (+ the nit pid in a second > > > > > > > thread) while dvbscan creates up to 32 (iirc), so dvbscan is a > > > > > > > bit faster, but maybe your device/driver doesn't like it.) > > > > > > > > > > > > 1. That sounds VERY interesting! so please WHERE in scan's source > > > > > > code can I reduce the pid filtering to ONE PID and how. I do not > > > > > > call myself a programmer, so can you please give me a hint where > > > > > > I can find the appropriate sections in latest "scan.c" to patch > > > > > > that thing? It indeed would save me a lot of pain if I only knew > > > > > > where to look at and what to patch! :) > > > > > > try to decrease MAX_RUNNING in scan.c > > > > > > (btw, something may be wrong with your mail reader, as you see your > > > response was double quoted.) > > > > Thank you for that hint, Christophe. :) > > > > Reducing "define MAX_RUNNING=1" instead of 27 in fact slows down the > > whole process, but the real problem unfortunately stays. > > In fact I have tried a couple of numbers: 1, 2, 10, 20...... > > > > 7 walkthroughs - 7 different scan results. :( > > WHERE the timeouts happen is highly "by chance". :( > > There are channels missing in one walkthrough that appear in another and > > so on....... > > > > The scan result you can never call "standardized" or equal, as the number > > of dumped services is never at least close to equal. :( > > > > Kaffeine's scan result appears far more confidential than the one of > > "scan". > > > > Any other hints from your part where I could poke around in scan.c to > > resolve that issue??? > > Unfortunately, no :( Ok - that's what I expected, unfortunately. :( Moreover I forgot to mention that if I start a DVB-Scan after certain walkthroughs the filter timeout pid problem appears right after trying the first transponder (= initial transponder), which is equal to a card driver oops. Consequence: The machine must be shutdown (i. e. NO soft reset helps!), then be restarted, and then "scan" got to be run again. That appears like a "plug and pray issue", highly Microsoft-compatible! My card is a Pinnacle PCTVSAT PCI, i. e. a bt8xx-based DVB-S card, whose drivers are maintained (well, whatever that means in this very special example) by Manu Abraham. I did a little research in the dvb-apps repository, and noticed that very long time ago Johannes Stezenbach pulled in a patch to lower down the maximum number of running pids from 32 to 27. Whatever card he used as a reference or even proof that this would help to resolve the filter timeout pid issue remains a secret for me until today. So the perspective is to wait until Mister Abraham has finished his cx878 project (or should I call that a dead born child either?). As four unusable kernels (at least for bt8xx-based DVB cards - 2.6.13 - 16) showed in the past the ultimate Abraham-based top record of waitstates amounts to 9 months. I wonder if he can top that this time! So I am forced to build up a deeply horrible list scan feature as part of my TCL-TK-project, because if I do the channel scan transponder by transponder (i. e. list-oriented), using parameter -c plus a loop I get reliable scan results. That's highly time consuming, but that at least works. This option I wanted to avoid - this is what we call bad fate! > > P.S. > I've just added check for CA descriptors in PMT to correct CA flag in some > cases. In kaffeine I suppose - looking forward to kaffeine's next release. :( Many thanks for your hints! Best regards Uwe _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
