Re: [linux-dvb] extra switch for tzap
Hi, Am Freitag, 20. Juli 2007 12:37 schrieb P. van Gaans: > diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily. If you clone dvb-apps with hg you can simply do "hg diff" to get the modifications. The other possibility is to copy the whole directory before modifying and to diff them recursively (-r) afterwards. Anyway, doesn't matter here anymore - I'll deal with the stuff you attached (+ fix a bit coding style :) > Tzap was patched already. > Szap patched, compiles, tested and OK. > Czap patched, compiles without errors, untested because I hate my cable > provider and the box I would have to install the cable card in is really > noisy and unstable. Whoever wants to test: please report results, czap > looks a little different from szap and tzap but I'm pretty certain it'll > work straightaway. I assume this is OK, you couldn't expect all linuxtv > developers to own cards for all DVB-systems anyway.. > Femon patched in a different way: Femon already has a "human readable" > switch, I just made BER and uncorrected show up as decimal instead of > hex in human readable mode. Adding another switch sounds pointless to me. Hmm, maybe the same switch name should be used everywhere, for example "-H" (for human readable)? > The numbers/output seem to differ between devices and between szap and > tzap greatly so for now I'm not going to try to make them more > human-readable because of the possibility of breaking something. > > Everything attached. Thanks, Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
On Mon, 23 Jul 2007, Nico Sabbi wrote: > Uwe Bugla wrote: > > Am Sonntag, 22. Juli 2007 13:44:44 schrieb timecop: > >>I propose we setup #linuxtv-without-jews on feenode and coordinate our > >>efforts to take over those fools who run the real LinuxTV scam. > >> > >>-tc > > > > Hello tc, > > could you please stay off from here with such a no-brain antisemitistic > > verbal crap? > > > > Thanks > > > > Uwe > > generally I don't reply to Uwe's mails, but I have to say that tc's > sentence is one of the most horrible thing I ever read in any mailing > list. Those things can't be said neither seriously nor for kidding. Shame! > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb I had and still have, the person in question, spams filtered to 'delete' since long ago. I'm sure other people have done the same, however the replies seem to make it through. Another filter should fix it. Jules. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Uwe Bugla wrote: > Am Sonntag, 22. Juli 2007 13:44:44 schrieb timecop: > >>I propose we setup #linuxtv-without-jews on feenode and coordinate our >>efforts to take over those fools who run the real LinuxTV scam. >> >>-tc > > > Hello tc, > could you please stay off from here with such a no-brain antisemitistic > verbal > crap? > > Thanks > > Uwe generally I don't reply to Uwe's mails, but I have to say that tc's sentence is one of the most horrible thing I ever read in any mailing list. Those things can't be said neither seriously nor for kidding. Shame! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Am Sonntag, 22. Juli 2007 17:37:48 schrieb Christophe Thommeret: > Le dimanche 22 juillet 2007 13:44, timecop a écrit : > > I propose we setup #linuxtv-without-jews on feenode and coordinate our > > efforts to take over those fools who run the real LinuxTV scam. > > > > -tc > > FYI, I've just forwarded this mail to www.licra.org Salut Christophe, Forwarding the message of this timecop idiot to licra.org may be politically correct and consequent in a left or progressive point of view that I share with you. But IMHO you are just paying too much attention to that idiot. Timecop is not only stupid and dumb as dumb can be (According to Einstein dumbness is endless as you surely know), but moreover he is a good example that even blacks are not free from racism and antisemitism. I do not want to overestimate people like timecop, but Malcolm X is another sad example for that basic thesis. See, Christophe, if you spend a whole lot of life time for demonstrating against warfare and racism, and if you, like me, live 10 kilometers away from the Nato headquarter you can easily see what intellectual weight class of American folks the government hires to transform no brains into killer machines to be sent to Iraq and Afghanistan f. ex. The prototype of an American soldier is and was and always will be a no brain human being! So it's best to simply ignore people like timecop. If noone pays attention to people of his intellectual weight class he'll piss off himself! And I also think he is a shame for the international gays movement too. Au revoir On se verra Uwe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Le dimanche 22 juillet 2007 13:44, timecop a écrit : > I propose we setup #linuxtv-without-jews on feenode and coordinate our > efforts to take over those fools who run the real LinuxTV scam. > > -tc FYI, I've just forwarded this mail to www.licra.org -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
pot calling the kettle black anyone? On 7/22/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > Am Sonntag, 22. Juli 2007 13:44:44 schrieb timecop: > > I propose we setup #linuxtv-without-jews on feenode and coordinate our > > efforts to take over those fools who run the real LinuxTV scam. > > > > -tc > > Hello tc, > could you please stay off from here with such a no-brain antisemitistic verbal > crap? > > Thanks > > Uwe > > > > > On 7/22/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > > Am Sonntag, 22. Juli 2007 12:41:56 schrieb Johannes Stezenbach: > > > > On Sun, Jul 22, 2007, Uwe Bugla wrote: > > > > > As announced I've built a revised tarball plus a Debian package of > > > > > the current dvb-apps repository, implying your patchset (i. e. human > > > > > readable characters as a switch for szap, tzap and czap. > > > > > > > > > > Unfortunately both packages were rejected without giving reason by > > > > > the list moderator of [EMAIL PROTECTED] > > > > > > > > If you look at the reject messages, they should say: > > > > > > > > Reason: Message body is too big: 404226 bytes with a limit of 60 KB > > > > and > > > > Reason: Message body is too big: 517891 bytes with a limit of 60 KB > > > > > > > > The limit is there to protect people who don't have broadband > > > > connectivity, and to protect the list server (with ~2000 list > > > > subscribers, these two mails would have caused ~1.8 GByte of traffic). > > > > > > > > > > > > Johannes > > > > > > Sounds logical. But the main reason you unfortunately forgot to mention: > > > > > > The limit is there to protect the "highly motivated illustrious" linuxtv > > > gatekeepers from doing additional good work in order to share good > > > efforts all around the world. > > > > > > I still got my own experiences and views on the difference between what > > > real sophisticated maintainership means in practice @linuxtv.org in > > > comparison to the rest of the world-wide linux community. In fact there > > > is a big difference. > > > > > > For example, if I read comments like "you should first ask whether > > > someone intends to pick it up (by Christoph Pfister in this specific > > > example) the knife in my pocket opens. > > > A real sophisticated maintainer picks up such efforts like P. van Gaans > > > patch set and merges them without making any noise. > > > > > > Above that, the filter timeout problem in connection with "scan" still > > > remains unsolved (wasn't it you, Johannes, who once wrote the scan > > > utility?). > > > > > > Why is the scan result still such a drag? Why are the scan results so > > > unreliable? Why are there channels missing in the final result? > > > Is it a driver issue or an application issue? > > > And who can help? Who has got the clue to fix that? > > > And why does this problem not appear within kaffeine's channel scan? > > > > > > I'm not expecting any answer or fix for that problem - I can help myself. > > > But I would like to know whether I am the only one to have that problem > > > with the scan utility. > > > > > > Uwe > > > > > > > ___ > > > > linux-dvb mailing list > > > > linux-dvb@linuxtv.org > > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > > > ___ > > > linux-dvb mailing list > > > linux-dvb@linuxtv.org > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Am Sonntag, 22. Juli 2007 13:44:44 schrieb timecop: > I propose we setup #linuxtv-without-jews on feenode and coordinate our > efforts to take over those fools who run the real LinuxTV scam. > > -tc Hello tc, could you please stay off from here with such a no-brain antisemitistic verbal crap? Thanks Uwe > > On 7/22/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > Am Sonntag, 22. Juli 2007 12:41:56 schrieb Johannes Stezenbach: > > > On Sun, Jul 22, 2007, Uwe Bugla wrote: > > > > As announced I've built a revised tarball plus a Debian package of > > > > the current dvb-apps repository, implying your patchset (i. e. human > > > > readable characters as a switch for szap, tzap and czap. > > > > > > > > Unfortunately both packages were rejected without giving reason by > > > > the list moderator of [EMAIL PROTECTED] > > > > > > If you look at the reject messages, they should say: > > > > > > Reason: Message body is too big: 404226 bytes with a limit of 60 KB > > > and > > > Reason: Message body is too big: 517891 bytes with a limit of 60 KB > > > > > > The limit is there to protect people who don't have broadband > > > connectivity, and to protect the list server (with ~2000 list > > > subscribers, these two mails would have caused ~1.8 GByte of traffic). > > > > > > > > > Johannes > > > > Sounds logical. But the main reason you unfortunately forgot to mention: > > > > The limit is there to protect the "highly motivated illustrious" linuxtv > > gatekeepers from doing additional good work in order to share good > > efforts all around the world. > > > > I still got my own experiences and views on the difference between what > > real sophisticated maintainership means in practice @linuxtv.org in > > comparison to the rest of the world-wide linux community. In fact there > > is a big difference. > > > > For example, if I read comments like "you should first ask whether > > someone intends to pick it up (by Christoph Pfister in this specific > > example) the knife in my pocket opens. > > A real sophisticated maintainer picks up such efforts like P. van Gaans > > patch set and merges them without making any noise. > > > > Above that, the filter timeout problem in connection with "scan" still > > remains unsolved (wasn't it you, Johannes, who once wrote the scan > > utility?). > > > > Why is the scan result still such a drag? Why are the scan results so > > unreliable? Why are there channels missing in the final result? > > Is it a driver issue or an application issue? > > And who can help? Who has got the clue to fix that? > > And why does this problem not appear within kaffeine's channel scan? > > > > I'm not expecting any answer or fix for that problem - I can help myself. > > But I would like to know whether I am the only one to have that problem > > with the scan utility. > > > > Uwe > > > > > ___ > > > linux-dvb mailing list > > > linux-dvb@linuxtv.org > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
I propose we setup #linuxtv-without-jews on feenode and coordinate our efforts to take over those fools who run the real LinuxTV scam. -tc On 7/22/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > Am Sonntag, 22. Juli 2007 12:41:56 schrieb Johannes Stezenbach: > > On Sun, Jul 22, 2007, Uwe Bugla wrote: > > > As announced I've built a revised tarball plus a Debian package of the > > > current dvb-apps repository, implying your patchset (i. e. human readable > > > characters as a switch for szap, tzap and czap. > > > > > > Unfortunately both packages were rejected without giving reason by the > > > list moderator of [EMAIL PROTECTED] > > > > If you look at the reject messages, they should say: > > > > Reason: Message body is too big: 404226 bytes with a limit of 60 KB > > and > > Reason: Message body is too big: 517891 bytes with a limit of 60 KB > > > > The limit is there to protect people who don't have broadband > > connectivity, and to protect the list server (with ~2000 list > > subscribers, these two mails would have caused ~1.8 GByte of traffic). > > > > > > Johannes > > > > Sounds logical. But the main reason you unfortunately forgot to mention: > > The limit is there to protect the "highly motivated illustrious" linuxtv > gatekeepers from doing additional good work in order to share good efforts > all around the world. > > I still got my own experiences and views on the difference between what real > sophisticated maintainership means in practice @linuxtv.org in comparison to > the rest of the world-wide linux community. In fact there is a big > difference. > > For example, if I read comments like "you should first ask whether someone > intends to pick it up (by Christoph Pfister in this specific example) the > knife in my pocket opens. > A real sophisticated maintainer picks up such efforts like P. van Gaans patch > set and merges them without making any noise. > > Above that, the filter timeout problem in connection with "scan" still remains > unsolved (wasn't it you, Johannes, who once wrote the scan utility?). > > Why is the scan result still such a drag? Why are the scan results so > unreliable? Why are there channels missing in the final result? > Is it a driver issue or an application issue? > And who can help? Who has got the clue to fix that? > And why does this problem not appear within kaffeine's channel scan? > > I'm not expecting any answer or fix for that problem - I can help myself. > But I would like to know whether I am the only one to have that problem with > the scan utility. > > Uwe > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Am Sonntag, 22. Juli 2007 12:41:56 schrieb Johannes Stezenbach: > On Sun, Jul 22, 2007, Uwe Bugla wrote: > > As announced I've built a revised tarball plus a Debian package of the > > current dvb-apps repository, implying your patchset (i. e. human readable > > characters as a switch for szap, tzap and czap. > > > > Unfortunately both packages were rejected without giving reason by the > > list moderator of [EMAIL PROTECTED] > > If you look at the reject messages, they should say: > > Reason: Message body is too big: 404226 bytes with a limit of 60 KB > and > Reason: Message body is too big: 517891 bytes with a limit of 60 KB > > The limit is there to protect people who don't have broadband > connectivity, and to protect the list server (with ~2000 list > subscribers, these two mails would have caused ~1.8 GByte of traffic). > > > Johannes > Sounds logical. But the main reason you unfortunately forgot to mention: The limit is there to protect the "highly motivated illustrious" linuxtv gatekeepers from doing additional good work in order to share good efforts all around the world. I still got my own experiences and views on the difference between what real sophisticated maintainership means in practice @linuxtv.org in comparison to the rest of the world-wide linux community. In fact there is a big difference. For example, if I read comments like "you should first ask whether someone intends to pick it up (by Christoph Pfister in this specific example) the knife in my pocket opens. A real sophisticated maintainer picks up such efforts like P. van Gaans patch set and merges them without making any noise. Above that, the filter timeout problem in connection with "scan" still remains unsolved (wasn't it you, Johannes, who once wrote the scan utility?). Why is the scan result still such a drag? Why are the scan results so unreliable? Why are there channels missing in the final result? Is it a driver issue or an application issue? And who can help? Who has got the clue to fix that? And why does this problem not appear within kaffeine's channel scan? I'm not expecting any answer or fix for that problem - I can help myself. But I would like to know whether I am the only one to have that problem with the scan utility. Uwe > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
On Sun, Jul 22, 2007, Uwe Bugla wrote: > > As announced I've built a revised tarball plus a Debian package of the > current > dvb-apps repository, implying your patchset (i. e. human readable characters > as a switch for szap, tzap and czap. > > Unfortunately both packages were rejected without giving reason by the list > moderator of [EMAIL PROTECTED] If you look at the reject messages, they should say: Reason: Message body is too big: 404226 bytes with a limit of 60 KB and Reason: Message body is too big: 517891 bytes with a limit of 60 KB The limit is there to protect people who don't have broadband connectivity, and to protect the list server (with ~2000 list subscribers, these two mails would have caused ~1.8 GByte of traffic). Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] extra switch for tzap, czap and szap - new tarball and Debian package
Hi, As announced I've built a revised tarball plus a Debian package of the current dvb-apps repository, implying your patchset (i. e. human readable characters as a switch for szap, tzap and czap. Unfortunately both packages were rejected without giving reason by the list moderator of [EMAIL PROTECTED] I still want to share that work. As soon as my project will be ready I will be going to host stuff like that on my own project page at sourceforge. If someone needs one or both of the packages please drop me a short note. Uwe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap, problems with the scan utility: filter timeout pid appearing very often
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
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 :( P.S. I've just added check for CA descriptors in PMT to correct CA flag in some cases. -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
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??? Would be a pleasure! :) Best regards Uwe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
2007/7/20, Uwe Bugla <[EMAIL PROTECTED]>: > Am Freitag, 20. Juli 2007 16:43:07 schrieben Sie: > > Am Freitag, 20. Juli 2007 16:15 schrieb Uwe Bugla: > > > By the way, Fathi Boudra still did not solve that language interface > > > problem in kaffeine 0.8.4 DEBIAN SID package. > > > If people do report that earlier Debian packages worked out well and did > > > not show that bug at all I do wonder why the Debian packagers make such a > > > science out of a simple stupid packaging script error. :( > > > > CRAP. Fixed since 18 Jul 2007 18:01:13 +0200 (just that i386 buildd doesn't > > work properly atm - but that's part of the deal when using sid). > > OK, if I am talking crap in your whole opinion then I would like to know: > > - what or where buildd is (I didn't find it with kpackage) Google is your friend - http://buildd.debian.org > - where the revision of kaffeine 0.8.4 stays (I am doing daily upgrades, but I > haven't seen any revision of kaffeine's Debian package yet). yet-to-be-built (because buildd is down; but all necessary stuff to build it is uploaded since the date indicated above). > > Christoph > > Uwe Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Freitag, 20. Juli 2007 16:43:07 schrieben Sie: > Am Freitag, 20. Juli 2007 16:15 schrieb Uwe Bugla: > > By the way, Fathi Boudra still did not solve that language interface > > problem in kaffeine 0.8.4 DEBIAN SID package. > > If people do report that earlier Debian packages worked out well and did > > not show that bug at all I do wonder why the Debian packagers make such a > > science out of a simple stupid packaging script error. :( > > CRAP. Fixed since 18 Jul 2007 18:01:13 +0200 (just that i386 buildd doesn't > work properly atm - but that's part of the deal when using sid). OK, if I am talking crap in your whole opinion then I would like to know: - what or where buildd is (I didn't find it with kpackage) - where the revision of kaffeine 0.8.4 stays (I am doing daily upgrades, but I haven't seen any revision of kaffeine's Debian package yet). > > > Best regards > > > > Uwe > > Christoph Uwe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Freitag, 20. Juli 2007 16:26:27 schrieben Sie: > Uwe Bugla wrote: > > Am Freitag, 20. Juli 2007 12:37:45 schrieben Sie: > >> Uwe Bugla wrote: > >>> Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie: > Uwe Bugla wrote: > > Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > >> I don't call myself a programmer (I've never seen any C guide), but > >> somehow I figured out how to add an extra switch to tzap to make it > >> print the status in (human-readable) decimal instead of hex. It is > >> attached. It would be really nice if this would make it into the > >> dvb-apps on linuxtv.. > >> > >> Talking about that, could anybody tell me the minimal and maximal > >> and/or possible values for status, signal, snr, ber and uncorrected? > >> If I would know them I could try to make the numbers more > >> human-readable (eg signal ranging from 0 to 99 or so). > > > > Could you please redo that: > > - in patch format (=only the additions) > > - equally for tzap, czap, szap and femon? > > > > Thus everybody could take advantage from that idea. > > Would be a pleasure for us all if you did! > > > > My idea for further enlargement (a quite old idea of mine): > > route the human readable numbers into a speech recognition engine > > (festival) to make them auditable and thus real usable for DVB-S dish > > tuning f. ex. > > > > Note: If the DVB-S dish is far away from the machine (card), > > auditable signals are necessary. > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > In patch format.. Oh please.. I have no idea how to produce that! I > installed xxdiff, it perfectly shows what I've changed but I don't see > an option to save it to a patch file! > > You're lucky I've got a satellite dish so I should also be able to > patch szap and femon. I'll also produce a patched version of czap but > my cable card is not installed ATM and I don't feel like doing so > (cable provider is crap) but I'll probably get someone else on this > list to test it. > > Please do not try to add the switch yourself without asking me if I'm > still working on it. Nobody needs double work. > > If somebody can tell me how to produce the so much wanted .diff files > I'll start working on it. > >>> > >>> A. Take the latest kernel patch (i. e. 2.6.21.1) as an example. > >>> B. format is as follows: > >>> --- a/(file to be changed) > >>> +++ b/(file to be changed) > >>> @@ -(starting line number),(total number of lines starting from the > >>> beginning line before the change) +(starting line number),(total number > >>> of lines starting from the beginning line after the change) > >>> (3 context lines starting with a space) > >>> (additions start with plus) > >>> (deletions start with minus) > >>> (3 context lines starting with a space) > >>> > >>> If this explanation still is too abstract, have a look at the example > >>> again. Don't forget to test the patch! > >>> No fuzz factors, no rejections please. > >>> For testing purposes keep the original file to be patched in a separate > >>> directory please. > >>> Now please give it a try - for sure you gonna make it! > >> > >> I've got an idea of how the .diff is constructed, but I simply refuse to > >> write them by hand. I've bought a computer NOT to do any more boring > >> repetitive work ;-). > >> > >> diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily. > >> > >> Tzap was patched already. > >> Szap patched, compiles, tested and OK. > >> Czap patched, compiles without errors, untested because I hate my cable > >> provider and the box I would have to install the cable card in is really > >> noisy and unstable. Whoever wants to test: please report results, czap > >> looks a little different from szap and tzap but I'm pretty certain it'll > >> work straightaway. I assume this is OK, you couldn't expect all linuxtv > >> developers to own cards for all DVB-systems anyway.. > >> Femon patched in a different way: Femon already has a "human readable" > >> switch, I just made BER and uncorrected show up as decimal instead of > >> hex in human readable mode. Adding another switch sounds pointless to > >> me. > >> > >> The numbers/output seem to differ between devices and between szap and > >> tzap greatly so for now I'm not going to try to make them more > >> human-readable because of the possibility of breaking something. > >> > >> Everything attached. > > > > Thank you very much! > > > > Now if some of the "illustrous" may consacre a bit of time to push that > > into the dvb-apps tree it would be real purrfect! > > Because you were telling me what to do, I thought you were a developer.. > > Exciting.. I hope that work wasn't for nothing. No! No w
Re: [linux-dvb] extra switch for tzap
Am Freitag, 20. Juli 2007 16:15 schrieb Uwe Bugla: > By the way, Fathi Boudra still did not solve that language interface > problem in kaffeine 0.8.4 DEBIAN SID package. > If people do report that earlier Debian packages worked out well and did > not show that bug at all I do wonder why the Debian packagers make such a > science out of a simple stupid packaging script error. :( CRAP. Fixed since 18 Jul 2007 18:01:13 +0200 (just that i386 buildd doesn't work properly atm - but that's part of the deal when using sid). > Best regards > > Uwe Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Uwe Bugla wrote: > Am Freitag, 20. Juli 2007 12:37:45 schrieben Sie: >> Uwe Bugla wrote: >>> Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie: Uwe Bugla wrote: > Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: >> I don't call myself a programmer (I've never seen any C guide), but >> somehow I figured out how to add an extra switch to tzap to make it >> print the status in (human-readable) decimal instead of hex. It is >> attached. It would be really nice if this would make it into the >> dvb-apps on linuxtv.. >> >> Talking about that, could anybody tell me the minimal and maximal >> and/or possible values for status, signal, snr, ber and uncorrected? >> If I would know them I could try to make the numbers more >> human-readable (eg signal ranging from 0 to 99 or so). > Could you please redo that: > - in patch format (=only the additions) > - equally for tzap, czap, szap and femon? > > Thus everybody could take advantage from that idea. > Would be a pleasure for us all if you did! > > My idea for further enlargement (a quite old idea of mine): > route the human readable numbers into a speech recognition engine > (festival) to make them auditable and thus real usable for DVB-S dish > tuning f. ex. > > Note: If the DVB-S dish is far away from the machine (card), auditable > signals are necessary. > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb In patch format.. Oh please.. I have no idea how to produce that! I installed xxdiff, it perfectly shows what I've changed but I don't see an option to save it to a patch file! You're lucky I've got a satellite dish so I should also be able to patch szap and femon. I'll also produce a patched version of czap but my cable card is not installed ATM and I don't feel like doing so (cable provider is crap) but I'll probably get someone else on this list to test it. Please do not try to add the switch yourself without asking me if I'm still working on it. Nobody needs double work. If somebody can tell me how to produce the so much wanted .diff files I'll start working on it. >>> A. Take the latest kernel patch (i. e. 2.6.21.1) as an example. >>> B. format is as follows: >>> --- a/(file to be changed) >>> +++ b/(file to be changed) >>> @@ -(starting line number),(total number of lines starting from the >>> beginning line before the change) +(starting line number),(total number >>> of lines starting from the beginning line after the change) >>> (3 context lines starting with a space) >>> (additions start with plus) >>> (deletions start with minus) >>> (3 context lines starting with a space) >>> >>> If this explanation still is too abstract, have a look at the example >>> again. Don't forget to test the patch! >>> No fuzz factors, no rejections please. >>> For testing purposes keep the original file to be patched in a separate >>> directory please. >>> Now please give it a try - for sure you gonna make it! >> I've got an idea of how the .diff is constructed, but I simply refuse to >> write them by hand. I've bought a computer NOT to do any more boring >> repetitive work ;-). >> >> diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily. >> >> Tzap was patched already. >> Szap patched, compiles, tested and OK. >> Czap patched, compiles without errors, untested because I hate my cable >> provider and the box I would have to install the cable card in is really >> noisy and unstable. Whoever wants to test: please report results, czap >> looks a little different from szap and tzap but I'm pretty certain it'll >> work straightaway. I assume this is OK, you couldn't expect all linuxtv >> developers to own cards for all DVB-systems anyway.. >> Femon patched in a different way: Femon already has a "human readable" >> switch, I just made BER and uncorrected show up as decimal instead of >> hex in human readable mode. Adding another switch sounds pointless to me. >> >> The numbers/output seem to differ between devices and between szap and >> tzap greatly so for now I'm not going to try to make them more >> human-readable because of the possibility of breaking something. >> >> Everything attached. > > Thank you very much! > > Now if some of the "illustrous" may consacre a bit of time to push that into > the dvb-apps tree it would be real purrfect! > Because you were telling me what to do, I thought you were a developer.. Exciting.. I hope that work wasn't for nothing. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Freitag, 20. Juli 2007 15:03:55 schrieben Sie: > 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 > Thanks! :) I will gonna try that one. And I really hope that the timeout pid issue will be past then forever! > (btw, something may be wrong with your mail reader, as you see your > response was double quoted.) Well, it's sometimes on strike out of a timeout issue (i. e. the server refuses to forward outgoing Emails telling me something about a authentification error. But when I reboot the machine everything will be OKIDOK. By the way, Fathi Boudra still did not solve that language interface problem in kaffeine 0.8.4 DEBIAN SID package. If people do report that earlier Debian packages worked out well and did not show that bug at all I do wonder why the Debian packagers make such a science out of a simple stupid packaging script error. :( Best regards Uwe ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
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.) -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Freitag, 20. Juli 2007 13:12:40 schrieben Sie: > Am Freitag, 20. Juli 2007 12:37:45 schrieben Sie: > > Uwe Bugla wrote: > > > Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie: > > >> Uwe Bugla wrote: > > >>> Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > > I don't call myself a programmer (I've never seen any C guide), but > > somehow I figured out how to add an extra switch to tzap to make it > > print the status in (human-readable) decimal instead of hex. It is > > attached. It would be really nice if this would make it into the > > dvb-apps on linuxtv.. > > > > Talking about that, could anybody tell me the minimal and maximal > > and/or possible values for status, signal, snr, ber and uncorrected? > > If I would know them I could try to make the numbers more > > human-readable (eg signal ranging from 0 to 99 or so). > > >>> > > >>> Could you please redo that: > > >>> - in patch format (=only the additions) > > >>> - equally for tzap, czap, szap and femon? > > >>> > > >>> Thus everybody could take advantage from that idea. > > >>> Would be a pleasure for us all if you did! > > >>> > > >>> My idea for further enlargement (a quite old idea of mine): > > >>> route the human readable numbers into a speech recognition engine > > >>> (festival) to make them auditable and thus real usable for DVB-S dish > > >>> tuning f. ex. > > >>> > > >>> Note: If the DVB-S dish is far away from the machine (card), > > >>> auditable signals are necessary. > > >>> > > >>> ___ > > >>> linux-dvb mailing list > > >>> linux-dvb@linuxtv.org > > >>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > >> > > >> In patch format.. Oh please.. I have no idea how to produce that! I > > >> installed xxdiff, it perfectly shows what I've changed but I don't see > > >> an option to save it to a patch file! > > >> > > >> You're lucky I've got a satellite dish so I should also be able to > > >> patch szap and femon. I'll also produce a patched version of czap but > > >> my cable card is not installed ATM and I don't feel like doing so > > >> (cable provider is crap) but I'll probably get someone else on this > > >> list to test it. > > >> > > >> Please do not try to add the switch yourself without asking me if I'm > > >> still working on it. Nobody needs double work. > > >> > > >> If somebody can tell me how to produce the so much wanted .diff files > > >> I'll start working on it. > > > > > > A. Take the latest kernel patch (i. e. 2.6.21.1) as an example. > > > B. format is as follows: > > > --- a/(file to be changed) > > > +++ b/(file to be changed) > > > @@ -(starting line number),(total number of lines starting from the > > > beginning line before the change) +(starting line number),(total number > > > of lines starting from the beginning line after the change) > > > (3 context lines starting with a space) > > > (additions start with plus) > > > (deletions start with minus) > > > (3 context lines starting with a space) > > > > > > If this explanation still is too abstract, have a look at the example > > > again. Don't forget to test the patch! > > > No fuzz factors, no rejections please. > > > For testing purposes keep the original file to be patched in a separate > > > directory please. > > > Now please give it a try - for sure you gonna make it! > > > > I've got an idea of how the .diff is constructed, but I simply refuse to > > write them by hand. I've bought a computer NOT to do any more boring > > repetitive work ;-). > > > > diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily. > > > > Tzap was patched already. > > Szap patched, compiles, tested and OK. > > Czap patched, compiles without errors, untested because I hate my cable > > provider and the box I would have to install the cable card in is really > > noisy and unstable. Whoever wants to test: please report results, czap > > looks a little different from szap and tzap but I'm pretty certain it'll > > work straightaway. I assume this is OK, you couldn't expect all linuxtv > > developers to own cards for all DVB-systems anyway.. > > Femon patched in a different way: Femon already has a "human readable" > > switch, I just made BER and uncorrected show up as decimal instead of > > hex in human readable mode. Adding another switch sounds pointless to me. > > > > The numbers/output seem to differ between devices and between szap and > > tzap greatly so for now I'm not going to try to make them more > > human-readable because of the possibility of breaking something. > > > > Everything attached. > > Thank you very much! > > Now if some of the "illustrous" may consacre a bit of time to push that > into the dvb-apps tree it would be real purrfect! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Uwe Bugla wrote:
Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie:
Uwe Bugla wrote:
Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans:
I don't call myself a programmer (I've never seen any C guide), but
somehow I figured out how to add an extra switch to tzap to make it
print the status in (human-readable) decimal instead of hex. It is
attached. It would be really nice if this would make it into the
dvb-apps on linuxtv..
Talking about that, could anybody tell me the minimal and maximal and/or
possible values for status, signal, snr, ber and uncorrected? If I would
know them I could try to make the numbers more human-readable (eg signal
ranging from 0 to 99 or so).
Could you please redo that:
- in patch format (=only the additions)
- equally for tzap, czap, szap and femon?
Thus everybody could take advantage from that idea.
Would be a pleasure for us all if you did!
My idea for further enlargement (a quite old idea of mine):
route the human readable numbers into a speech recognition engine
(festival) to make them auditable and thus real usable for DVB-S dish
tuning f. ex.
Note: If the DVB-S dish is far away from the machine (card), auditable
signals are necessary.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
In patch format.. Oh please.. I have no idea how to produce that! I
installed xxdiff, it perfectly shows what I've changed but I don't see
an option to save it to a patch file!
You're lucky I've got a satellite dish so I should also be able to patch
szap and femon. I'll also produce a patched version of czap but my cable
card is not installed ATM and I don't feel like doing so (cable provider
is crap) but I'll probably get someone else on this list to test it.
Please do not try to add the switch yourself without asking me if I'm
still working on it. Nobody needs double work.
If somebody can tell me how to produce the so much wanted .diff files
I'll start working on it.
A. Take the latest kernel patch (i. e. 2.6.21.1) as an example.
B. format is as follows:
--- a/(file to be changed)
+++ b/(file to be changed)
@@ -(starting line number),(total number of lines starting from the beginning
line before the change) +(starting line number),(total number of lines
starting from the beginning line after the change)
(3 context lines starting with a space)
(additions start with plus)
(deletions start with minus)
(3 context lines starting with a space)
If this explanation still is too abstract, have a look at the example again.
Don't forget to test the patch!
No fuzz factors, no rejections please.
For testing purposes keep the original file to be patched in a separate
directory please.
Now please give it a try - for sure you gonna make it!
I've got an idea of how the .diff is constructed, but I simply refuse to
write them by hand. I've bought a computer NOT to do any more boring
repetitive work ;-).
diff -urN oldfile.c newfile.c > lolwat.diff appears to work luckily.
Tzap was patched already.
Szap patched, compiles, tested and OK.
Czap patched, compiles without errors, untested because I hate my cable
provider and the box I would have to install the cable card in is really
noisy and unstable. Whoever wants to test: please report results, czap
looks a little different from szap and tzap but I'm pretty certain it'll
work straightaway. I assume this is OK, you couldn't expect all linuxtv
developers to own cards for all DVB-systems anyway..
Femon patched in a different way: Femon already has a "human readable"
switch, I just made BER and uncorrected show up as decimal instead of
hex in human readable mode. Adding another switch sounds pointless to me.
The numbers/output seem to differ between devices and between szap and
tzap greatly so for now I'm not going to try to make them more
human-readable because of the possibility of breaking something.
Everything attached.
--- czap-hg.c 2007-07-18 05:18:38.0 +0200
+++ czap.c 2007-07-20 11:58:35.0 +0200
@@ -16,6 +16,7 @@
static char FRONTEND_DEV [80];
static char DEMUX_DEV [80];
+static int decread=0;
static int exit_after_tuning;
#define CHANNEL_FILE "channels.conf"
@@ -241,9 +242,18 @@
ioctl(fe_fd, FE_READ_BER, &ber);
ioctl(fe_fd, FE_READ_UNCORRECTED_BLOCKS, &uncorrected_blocks);
- printf ("status %02x | signal %04x | snr %04x | "
+ if(decread==1)
+ {
+ printf ("status %d | signal %d | snr %d | "
+ "ber %d | unc %d | ",
+ status, signal, snr, ber, uncorrected_blocks);
+ }
+ else
+ {
+ printf ("status %02x | signal %04x | snr %04x | "
"ber %08x | unc %08x | ",
status, signal, snr, ber, uncorrected_blocks);
+ }
if (status & FE_HAS_LOCK)
printf("FE_HAS_LOCK");
@@ -261,7 +271,8 @@
static const char *usage = "\nusage: %s [-a adapter_num] [-f frontend_id] [-d demux_id] [-c conf_file] {| -n channel_num} [-x]\n"
- " or: %s [-c conf_file] -l\n\n";
+ "
Re: [linux-dvb] extra switch for tzap
Am Donnerstag, 19. Juli 2007 16:25:38 schrieben Sie: > Am Donnerstag, 19. Juli 2007 16:19:17 schrieben Sie: > > Am Donnerstag, 19. Juli 2007 12:35:14 schrieben Sie: > > > Le mercredi 18 juillet 2007 19:20, Uwe Bugla a écrit : > > > > Am Mittwoch, 18. Juli 2007 17:21:07 schrieben Sie: > > > > > Le mercredi 18 juillet 2007 16:13, Uwe Bugla a écrit : > > > > > > 2. Kaffeine's channel lists should not be sorted by a couple of > > > > > > numbers that absolutely do not make any sense. > > > > > > The sorting should be alphabetically in the first place, then > > > > > > using numbers. In a kaffeine channel list it's quite horrible to > > > > > > find a desired channel that you want to watch. > > > > > > > > Dear Christophe, first of all a thousands of thanks for your pretty > > > > nice hints :) > > > > > > np :) > > > > > > > > You can click on list headers to set sorting. > > > > > Numbers are quite useful and easy to remember (at least for most > > > > > viewed channels). You can change a channel' number by selecting the > > > > > channel in list then clicking again to edit. > > > > > Anyway, i don't know of any good method to quickly find a channel > > > > > in a list of thousands :) > > > > > > > > The alphabetic order is the most reliable one, no matter if the total > > > > number of channels is 10, 100 or even 1000 or more. > > > > > > I guess it's a matter of taste, i personnaly prefer number sorting ... > > > > > > > As an addition a bookmark system to sub-categorize the found channels > > > > would be "close to perfection." :) > > > > > > This one i don't get. Could you explain your idea? > > > > A bookmark can look like this (take german channels f. ex.): > > > > ___Erste___ followed by channels like: > > Das Erste > > Eins Plus > > Eins Extra > > Eins Festival > > > > ___Private___ > > RTL Television > > RTL 2 > > > > etc. ... > > > > Thus you can set up some sub-order in an endless list of thousands of > > channels. If you present the bookmarks in a vertical order you can omit > > the ordering numbers for the channels. > > > > > > As kaffeine is not too well documented :( the alphabetic order only > > > > does appear in the editor mode, not in the watching TV or radio mode. > > > > > > Headers sorting is quite standard however. > > > > Thank you! I already found the clue by intuition. :) > > > > > > > So you may want to delete useless channels (take a look, > > > > > you will find a lot :) to reduce the list length. > > > > > > > > This also should be done automatically (double and triple > > > > appearances, channels without a valid name appearing as "unknown" > > > > etc.). > > > > The primary direction should be: as little user inputs as necessary. > > > > > > That was the case in previous versions, but then users complained about > > > missing channels :) > > > > Lesson 1: Do never listen to crash test dummies! :) > > > > To automatically delete double and triple appearances may be in fact > > harmful sometimes, but there is no discussion about "unknown" channels, > > or is there any? > > > > > > > You can also take advantage of categories to group channels and so > > > > > deal with smaller lists. > > > > > > > > Never even tried that as I am missing features like this one in a > > > > proper documentation. > > > > > > Quoting the handbook: > > > "You can arrange your channels in categories. To create a new category, > > > right click in the icon view to get a popup menu. Now, drag a channel > > > name and drop it on the desired category' icon. To remove a channel > > > from a category, drop it on the "All" icon. Right click on an icon to > > > delete that category or change icon." > > > > Thanks! Am gonna look that up. I am just too lazy to read docus > > sometimes. > > > > > Not perfect, but at least the category feature is mentioned ;) > > > > > > > > P.S. > > > > > Kaffeine svn has a search field in channels list. > > > > > > > > P. S.: femonspeak is real working fine. If I find some time to do I > > > > will extend the spoken wav-part by two other core languages: German > > > > and French. Then will produce a Debian package to imply that tool > > > > into my TCL/TK project I am busily working on (which is trilingual at > > > > the current state of development). > > > > > > Yes, it works fine, i use it when i'm on the roof to adjust the dish ! > > > (with max volume and opened window :) > > > > YUP! But only using aplay (alsaplayer), never using play from sox! > > Using sox I was not successful at all! > > > > > > Uwe > > > > > > > > Master question 1: > > > > When I run a kaffeine channel scan I never stumble across "filter > > > > timeout pid" errors. > > > > > > > > When I do the same with "scan" out of the dvb-utils-package, filter > > > > timeouts appear very often and the scan result is neither mediocre > > > > nor even reliable, with or without the parameter -5. It's just utmost > > > > "crappy"! > > > > > > > > So please where is the clue in kaffeine's source code that makes its
Re: [linux-dvb] extra switch for tzap
Le mercredi 18 juillet 2007 19:20, Uwe Bugla a écrit : > Am Mittwoch, 18. Juli 2007 17:21:07 schrieben Sie: > > Le mercredi 18 juillet 2007 16:13, Uwe Bugla a écrit : > > > 2. Kaffeine's channel lists should not be sorted by a couple of numbers > > > that absolutely do not make any sense. > > > The sorting should be alphabetically in the first place, then using > > > numbers. In a kaffeine channel list it's quite horrible to find a > > > desired channel that you want to watch. > > Dear Christophe, first of all a thousands of thanks for your pretty nice > hints :) np :) > > You can click on list headers to set sorting. > > Numbers are quite useful and easy to remember (at least for most viewed > > channels). You can change a channel' number by selecting the channel in > > list then clicking again to edit. > > Anyway, i don't know of any good method to quickly find a channel in a > > list of thousands :) > > The alphabetic order is the most reliable one, no matter if the total > number of channels is 10, 100 or even 1000 or more. I guess it's a matter of taste, i personnaly prefer number sorting ... > As an addition a bookmark system to sub-categorize the found channels would > be "close to perfection." :) This one i don't get. Could you explain your idea? > As kaffeine is not too well documented :( the alphabetic order only does > appear in the editor mode, not in the watching TV or radio mode. Headers sorting is quite standard however. > > So you may want to delete useless channels (take a look, > > you will find a lot :) to reduce the list length. > > This also should be done automatically (double and triple appearances, > channels without a valid name appearing as "unknown" etc.). > The primary direction should be: as little user inputs as necessary. That was the case in previous versions, but then users complained about missing channels :) > > You can also take advantage of categories to group channels and so deal > > with smaller lists. > > Never even tried that as I am missing features like this one in a proper > documentation. Quoting the handbook: "You can arrange your channels in categories. To create a new category, right click in the icon view to get a popup menu. Now, drag a channel name and drop it on the desired category' icon. To remove a channel from a category, drop it on the "All" icon. Right click on an icon to delete that category or change icon." Not perfect, but at least the category feature is mentioned ;) > > P.S. > > Kaffeine svn has a search field in channels list. > > P. S.: femonspeak is real working fine. If I find some time to do I will > extend the spoken wav-part by two other core languages: German and French. > Then will produce a Debian package to imply that tool into my TCL/TK > project I am busily working on (which is trilingual at the current state of > development). Yes, it works fine, i use it when i'm on the roof to adjust the dish ! (with max volume and opened window :) > Uwe > > Master question 1: > When I run a kaffeine channel scan I never stumble across "filter timeout > pid" errors. > > When I do the same with "scan" out of the dvb-utils-package, filter > timeouts appear very often and the scan result is neither mediocre nor even > reliable, with or without the parameter -5. It's just utmost "crappy"! > > So please where is the clue in kaffeine's source code that makes its > channel scan perform so well and reliable (well: I would not say perfect, > but still far much better than "scan" ever was!)? Hm, it could be particular to your device/driver, cause here scan is still a reference. I think now kaffeine' scan is as good as dvbscan, but i won't say it's better. (at least dvbscan supports atsc, what kaffeine doesn't) (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.) > Master question 2: > In a channel scan result there are channels that are declared CA but are > FTA and vice versa. > How can this be corrected automatically? It's a well known problem, and i can't see any reliable solution apart that blaming providers. It would be possible to check for CA descriptors in PMT, but even some channels are unencrypted while PMT claim it is !! > My proposal would be: > List the channels by SID in a database or something similar, then > correcting the CA-flag automatically. (SID is not unique through a network, one would need a NetworkID/TransportStreamID/ServiceID combination to uniquely identify a channel) -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Donnerstag, 19. Juli 2007 02:29:34 schrieben Sie: > Uwe Bugla wrote: > > Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > >> I don't call myself a programmer (I've never seen any C guide), but > >> somehow I figured out how to add an extra switch to tzap to make it > >> print the status in (human-readable) decimal instead of hex. It is > >> attached. It would be really nice if this would make it into the > >> dvb-apps on linuxtv.. > >> > >> Talking about that, could anybody tell me the minimal and maximal and/or > >> possible values for status, signal, snr, ber and uncorrected? If I would > >> know them I could try to make the numbers more human-readable (eg signal > >> ranging from 0 to 99 or so). > > > > Could you please redo that: > > - in patch format (=only the additions) > > - equally for tzap, czap, szap and femon? > > > > Thus everybody could take advantage from that idea. > > Would be a pleasure for us all if you did! > > > > My idea for further enlargement (a quite old idea of mine): > > route the human readable numbers into a speech recognition engine > > (festival) to make them auditable and thus real usable for DVB-S dish > > tuning f. ex. > > > > Note: If the DVB-S dish is far away from the machine (card), auditable > > signals are necessary. > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > In patch format.. Oh please.. I have no idea how to produce that! I > installed xxdiff, it perfectly shows what I've changed but I don't see > an option to save it to a patch file! > > You're lucky I've got a satellite dish so I should also be able to patch > szap and femon. I'll also produce a patched version of czap but my cable > card is not installed ATM and I don't feel like doing so (cable provider > is crap) but I'll probably get someone else on this list to test it. > > Please do not try to add the switch yourself without asking me if I'm > still working on it. Nobody needs double work. > > If somebody can tell me how to produce the so much wanted .diff files > I'll start working on it. A. Take the latest kernel patch (i. e. 2.6.21.1) as an example. B. format is as follows: --- a/(file to be changed) +++ b/(file to be changed) @@ -(starting line number),(total number of lines starting from the beginning line before the change) +(starting line number),(total number of lines starting from the beginning line after the change) (3 context lines starting with a space) (additions start with plus) (deletions start with minus) (3 context lines starting with a space) If this explanation still is too abstract, have a look at the example again. Don't forget to test the patch! No fuzz factors, no rejections please. For testing purposes keep the original file to be patched in a separate directory please. Now please give it a try - for sure you gonna make it! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Donnerstag, den 19.07.2007, 10:28 +0900 schrieb timecop: > Perhaps an extra servings of dongs? But what about the sores then? > > -tc > > On 7/19/07, hermann pitton <[EMAIL PROTECTED]> wrote: > > Am Donnerstag, den 19.07.2007, 09:34 +0900 schrieb timecop: > > > diff -urN oldfile.c newfile.c > lolwat.diff > > > > What do you recommend should be in this .diff ? > > > > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Perhaps an extra servings of dongs? -tc On 7/19/07, hermann pitton <[EMAIL PROTECTED]> wrote: > Am Donnerstag, den 19.07.2007, 09:34 +0900 schrieb timecop: > > diff -urN oldfile.c newfile.c > lolwat.diff > > What do you recommend should be in this .diff ? > > > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Donnerstag, den 19.07.2007, 09:34 +0900 schrieb timecop: > diff -urN oldfile.c newfile.c > lolwat.diff What do you recommend should be in this .diff ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
diff -urN oldfile.c newfile.c > lolwat.diff On 7/19/07, P. van Gaans <[EMAIL PROTECTED]> wrote: > Uwe Bugla wrote: > > Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > >> I don't call myself a programmer (I've never seen any C guide), but > >> somehow I figured out how to add an extra switch to tzap to make it > >> print the status in (human-readable) decimal instead of hex. It is > >> attached. It would be really nice if this would make it into the > >> dvb-apps on linuxtv.. > >> > >> Talking about that, could anybody tell me the minimal and maximal and/or > >> possible values for status, signal, snr, ber and uncorrected? If I would > >> know them I could try to make the numbers more human-readable (eg signal > >> ranging from 0 to 99 or so). > > > > Could you please redo that: > > - in patch format (=only the additions) > > - equally for tzap, czap, szap and femon? > > > > Thus everybody could take advantage from that idea. > > Would be a pleasure for us all if you did! > > > > My idea for further enlargement (a quite old idea of mine): > > route the human readable numbers into a speech recognition engine (festival) > > to make them auditable and thus real usable for DVB-S dish tuning f. ex. > > > > Note: If the DVB-S dish is far away from the machine (card), auditable > > signals > > are necessary. > > > > ___ > > linux-dvb mailing list > > linux-dvb@linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > > > In patch format.. Oh please.. I have no idea how to produce that! I > installed xxdiff, it perfectly shows what I've changed but I don't see > an option to save it to a patch file! > > You're lucky I've got a satellite dish so I should also be able to patch > szap and femon. I'll also produce a patched version of czap but my cable > card is not installed ATM and I don't feel like doing so (cable provider > is crap) but I'll probably get someone else on this list to test it. > > Please do not try to add the switch yourself without asking me if I'm > still working on it. Nobody needs double work. > > If somebody can tell me how to produce the so much wanted .diff files > I'll start working on it. > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Uwe Bugla wrote: > Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: >> I don't call myself a programmer (I've never seen any C guide), but >> somehow I figured out how to add an extra switch to tzap to make it >> print the status in (human-readable) decimal instead of hex. It is >> attached. It would be really nice if this would make it into the >> dvb-apps on linuxtv.. >> >> Talking about that, could anybody tell me the minimal and maximal and/or >> possible values for status, signal, snr, ber and uncorrected? If I would >> know them I could try to make the numbers more human-readable (eg signal >> ranging from 0 to 99 or so). > > Could you please redo that: > - in patch format (=only the additions) > - equally for tzap, czap, szap and femon? > > Thus everybody could take advantage from that idea. > Would be a pleasure for us all if you did! > > My idea for further enlargement (a quite old idea of mine): > route the human readable numbers into a speech recognition engine (festival) > to make them auditable and thus real usable for DVB-S dish tuning f. ex. > > Note: If the DVB-S dish is far away from the machine (card), auditable > signals > are necessary. > > ___ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > In patch format.. Oh please.. I have no idea how to produce that! I installed xxdiff, it perfectly shows what I've changed but I don't see an option to save it to a patch file! You're lucky I've got a satellite dish so I should also be able to patch szap and femon. I'll also produce a patched version of czap but my cable card is not installed ATM and I don't feel like doing so (cable provider is crap) but I'll probably get someone else on this list to test it. Please do not try to add the switch yourself without asking me if I'm still working on it. Nobody needs double work. If somebody can tell me how to produce the so much wanted .diff files I'll start working on it. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Mittwoch, 18. Juli 2007 17:21:07 schrieben Sie: > Le mercredi 18 juillet 2007 16:13, Uwe Bugla a écrit : > > 2. Kaffeine's channel lists should not be sorted by a couple of numbers > > that absolutely do not make any sense. > > The sorting should be alphabetically in the first place, then using > > numbers. In a kaffeine channel list it's quite horrible to find a desired > > channel that you want to watch. > Dear Christophe, first of all a thousands of thanks for your pretty nice hints :) > You can click on list headers to set sorting. > Numbers are quite useful and easy to remember (at least for most viewed > channels). You can change a channel' number by selecting the channel in > list then clicking again to edit. > Anyway, i don't know of any good method to quickly find a channel in a list > of thousands :) The alphabetic order is the most reliable one, no matter if the total number of channels is 10, 100 or even 1000 or more. As an addition a bookmark system to sub-categorize the found channels would be "close to perfection." :) As kaffeine is not too well documented :( the alphabetic order only does appear in the editor mode, not in the watching TV or radio mode. > So you may want to delete useless channels (take a look, > you will find a lot :) to reduce the list length. This also should be done automatically (double and triple appearances, channels without a valid name appearing as "unknown" etc.). The primary direction should be: as little user inputs as necessary. > You can also take advantage of categories to group channels and so deal > with smaller lists. Never even tried that as I am missing features like this one in a proper documentation. > > P.S. > Kaffeine svn has a search field in channels list. P. S.: femonspeak is real working fine. If I find some time to do I will extend the spoken wav-part by two other core languages: German and French. Then will produce a Debian package to imply that tool into my TCL/TK project I am busily working on (which is trilingual at the current state of development). Uwe Master question 1: When I run a kaffeine channel scan I never stumble across "filter timeout pid" errors. When I do the same with "scan" out of the dvb-utils-package, filter timeouts appear very often and the scan result is neither mediocre nor even reliable, with or without the parameter -5. It's just utmost "crappy"! So please where is the clue in kaffeine's source code that makes its channel scan perform so well and reliable (well: I would not say perfect, but still far much better than "scan" ever was!)? Master question 2: In a channel scan result there are channels that are declared CA but are FTA and vice versa. How can this be corrected automatically? My proposal would be: List the channels by SID in a database or something similar, then correcting the CA-flag automatically. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Mittwoch, 18. Juli 2007 19:20:13 schrieben Sie: > Am Mittwoch, 18. Juli 2007 17:21:07 schrieben Sie: > > Le mercredi 18 juillet 2007 16:13, Uwe Bugla a écrit : > > > 2. Kaffeine's channel lists should not be sorted by a couple of numbers > > > that absolutely do not make any sense. > > > The sorting should be alphabetically in the first place, then using > > > numbers. In a kaffeine channel list it's quite horrible to find a > > > desired channel that you want to watch. > > Dear Christophe, first of all a thousands of thanks for your pretty nice > hints :) > > > You can click on list headers to set sorting. > > Numbers are quite useful and easy to remember (at least for most viewed > > channels). You can change a channel' number by selecting the channel in > > list then clicking again to edit. > > Anyway, i don't know of any good method to quickly find a channel in a > > list of thousands :) > > The alphabetic order is the most reliable one, no matter if the total > number of channels is 10, 100 or even 1000 or more. > > As an addition a bookmark system to sub-categorize the found channels would > be "close to perfection." :) > > As kaffeine is not too well documented :( the alphabetic order only does > appear in the editor mode, not in the watching TV or radio mode. > > > So you may want to delete useless channels (take a look, > > you will find a lot :) to reduce the list length. > > This also should be done automatically (double and triple appearances, > channels without a valid name appearing as "unknown" etc.). > The primary direction should be: as little user inputs as necessary. > > > You can also take advantage of categories to group channels and so deal > > with smaller lists. > > Never even tried that as I am missing features like this one in a proper > documentation. > > > P.S. > > Kaffeine svn has a search field in channels list. > > P. S.: femonspeak is real working fine. If I find some time to do I will > extend the spoken wav-part by two other core languages: German and French. > Then will produce a Debian package to imply that tool into my TCL/TK > project I am busily working on (which is trilingual at the current state of > development). > > Uwe > > Master question 1: > When I run a kaffeine channel scan I never stumble across "filter timeout > pid" errors. > > When I do the same with "scan" out of the dvb-utils-package, filter > timeouts appear very often and the scan result is neither mediocre nor even > reliable, with or without the parameter -5. It's just utmost "crappy"! > > So please where is the clue in kaffeine's source code that makes its > channel scan perform so well and reliable (well: I would not say perfect, > but still far much better than "scan" ever was!)? > > Master question 2: > In a channel scan result there are channels that are declared CA but are > FTA and vice versa. > How can this be corrected automatically? > My proposal would be: > List the channels by SID in a database or something similar, then > correcting the CA-flag automatically. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Le mercredi 18 juillet 2007 16:13, Uwe Bugla a écrit : > 2. Kaffeine's channel lists should not be sorted by a couple of numbers > that absolutely do not make any sense. > The sorting should be alphabetically in the first place, then using > numbers. In a kaffeine channel list it's quite horrible to find a desired > channel that you want to watch. You can click on list headers to set sorting. Numbers are quite usefull and easy to remember (at least for most viewed channels). You can change a channel' number by selecting the channel in list then clicking again to edit. Anyway, i don't know of any good method to quickly find a channel in a list of thousands :) So you may want to delete useless channels (take a look, you will find a lot :) to reduce the list length. You can also take advantage of categories to group channels and so deal with smaller lists. P.S. Kaffeine svn has a search field in channels list. -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Mittwoch, 18. Juli 2007 16:11:12 schrieben Sie: > Am Mittwoch, 18. Juli 2007 15:18:51 schrieben Sie: > > Am Mittwoch, 18. Juli 2007 11:44 schrieb Uwe Bugla: > > > > > > > - equally for tzap, czap, szap and femon? > > > > You should first check whether somebody intends to pick it up ... > > If there is noone (as very often here) then I will pick it up and at least > try to extend those tools with the switch in question, as the idea is > pretty good.. > Experience shows by a lot of examples that if you lay your ideas into the > hands of the small group of linuxtv.org people then you're simply lost in > most cases. > > Another option would be to extend the capabilities of femonspeak for DVB-T > and possibly DVB-C. I do not have such an equipment and thus cannot try. > > > > > > > Christoph > > Uwe > > P. S.: > 1. Installing the Debian package of kaffeine (0.8.4-5) (Debian Sid - KDE > 3.5.7) results in an english language interface on a German desktop > although the primary locale is de_DE and the necessary *.mo file is there. > I already sent in a bug report to the Debian community. > > 2. Kaffeine's channel lists should not be sorted by a couple of numbers > that absolutely do not make any sense. > The sorting should be alphabetically in the first place, then using > numbers. In a kaffeine channel list it's quite horrible to find a desired > channel that you want to watch. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Mittwoch, 18. Juli 2007 11:44 schrieb Uwe Bugla: > - equally for tzap, czap, szap and femon? You should first check whether somebody intends to pick it up ... Christoph ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Le mercredi 18 juillet 2007 11:44, Uwe Bugla a écrit : > My idea for further enlargement (a quite old idea of mine): > route the human readable numbers into a speech recognition engine > (festival) to make them auditable and thus real usable for DVB-S dish > tuning f. ex. > > Note: If the DVB-S dish is far away from the machine (card), auditable > signals are necessary. google femonspeak -- Christophe Thommeret ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
On Wed, 18 Jul 2007, Luca Olivetti wrote: > En/na P. van Gaans ha escrit: > > Talking about that, could anybody tell me the minimal and maximal and/or > > possible values for status, signal, snr, ber and uncorrected? If I would > > know them I could try to make the numbers more human-readable (eg signal > > ranging from 0 to 99 or so). > > The range and meaning of these values was specified in an older revision > of the dvb api. It's no longer specified, besides almost no driver > followed the former specification. Whats the not so obvious? How bout tzap providing range and meaning that IS specified in the newer dvb api? > Bye ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
Am Mittwoch, 18. Juli 2007 06:03:41 schrieb P. van Gaans: > I don't call myself a programmer (I've never seen any C guide), but > somehow I figured out how to add an extra switch to tzap to make it > print the status in (human-readable) decimal instead of hex. It is > attached. It would be really nice if this would make it into the > dvb-apps on linuxtv.. > > Talking about that, could anybody tell me the minimal and maximal and/or > possible values for status, signal, snr, ber and uncorrected? If I would > know them I could try to make the numbers more human-readable (eg signal > ranging from 0 to 99 or so). Could you please redo that: - in patch format (=only the additions) - equally for tzap, czap, szap and femon? Thus everybody could take advantage from that idea. Would be a pleasure for us all if you did! My idea for further enlargement (a quite old idea of mine): route the human readable numbers into a speech recognition engine (festival) to make them auditable and thus real usable for DVB-S dish tuning f. ex. Note: If the DVB-S dish is far away from the machine (card), auditable signals are necessary. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] extra switch for tzap
En/na P. van Gaans ha escrit: > Talking about that, could anybody tell me the minimal and maximal and/or > possible values for status, signal, snr, ber and uncorrected? If I would > know them I could try to make the numbers more human-readable (eg signal > ranging from 0 to 99 or so). The range and meaning of these values was specified in an older revision of the dvb api. It's no longer specified, besides almost no driver followed the former specification. Bye -- Luca ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] extra switch for tzap
I don't call myself a programmer (I've never seen any C guide), but
somehow I figured out how to add an extra switch to tzap to make it
print the status in (human-readable) decimal instead of hex. It is
attached. It would be really nice if this would make it into the
dvb-apps on linuxtv..
Talking about that, could anybody tell me the minimal and maximal and/or
possible values for status, signal, snr, ber and uncorrected? If I would
know them I could try to make the numbers more human-readable (eg signal
ranging from 0 to 99 or so).
/* tzap -- DVB-T zapping utility
*/
/*
* Added recording to a file
* arguments:
*
* -t timeout (seconds)
* -o filename output filename (use -o - for stdout)
* -s only print summary
* -S run silently (no output)
*
* Bernard Hatt 24/2/04
*/
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE 1
#define _LARGEFILE64_SOURCE 1
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static char FRONTEND_DEV [80];
static char DEMUX_DEV [80];
static char DVR_DEV [80];
static int timeout_flag=0;
static int silent=0,timeout=0;
static int decread=0;
static int exit_after_tuning;
#define CHANNEL_FILE "channels.conf"
#define ERROR(x...) \
do {\
fprintf(stderr, "ERROR: "); \
fprintf(stderr, x); \
fprintf (stderr, "\n"); \
} while (0)
#define PERROR(x...)\
do {\
fprintf(stderr, "ERROR: "); \
fprintf(stderr, x); \
fprintf (stderr, " (%s)\n", strerror(errno)); \
} while (0)
typedef struct {
char *name;
int value;
} Param;
static const Param inversion_list [] = {
{ "INVERSION_OFF", INVERSION_OFF },
{ "INVERSION_ON", INVERSION_ON },
{ "INVERSION_AUTO", INVERSION_AUTO }
};
static const Param bw_list [] = {
{ "BANDWIDTH_6_MHZ", BANDWIDTH_6_MHZ },
{ "BANDWIDTH_7_MHZ", BANDWIDTH_7_MHZ },
{ "BANDWIDTH_8_MHZ", BANDWIDTH_8_MHZ }
};
static const Param fec_list [] = {
{ "FEC_1_2", FEC_1_2 },
{ "FEC_2_3", FEC_2_3 },
{ "FEC_3_4", FEC_3_4 },
{ "FEC_4_5", FEC_4_5 },
{ "FEC_5_6", FEC_5_6 },
{ "FEC_6_7", FEC_6_7 },
{ "FEC_7_8", FEC_7_8 },
{ "FEC_8_9", FEC_8_9 },
{ "FEC_AUTO", FEC_AUTO },
{ "FEC_NONE", FEC_NONE }
};
static const Param guard_list [] = {
{"GUARD_INTERVAL_1_16", GUARD_INTERVAL_1_16},
{"GUARD_INTERVAL_1_32", GUARD_INTERVAL_1_32},
{"GUARD_INTERVAL_1_4", GUARD_INTERVAL_1_4},
{"GUARD_INTERVAL_1_8", GUARD_INTERVAL_1_8},
{"GUARD_INTERVAL_AUTO", GUARD_INTERVAL_AUTO}
};
static const Param hierarchy_list [] = {
{ "HIERARCHY_1", HIERARCHY_1 },
{ "HIERARCHY_2", HIERARCHY_2 },
{ "HIERARCHY_4", HIERARCHY_4 },
{ "HIERARCHY_NONE", HIERARCHY_NONE },
{ "HIERARCHY_AUTO", HIERARCHY_AUTO }
};
static const Param constellation_list [] = {
{ "QPSK", QPSK },
{ "QAM_128", QAM_128 },
{ "QAM_16", QAM_16 },
{ "QAM_256", QAM_256 },
{ "QAM_32", QAM_32 },
{ "QAM_64", QAM_64 },
{ "QAM_AUTO", QAM_AUTO }
};
static const Param transmissionmode_list [] = {
{ "TRANSMISSION_MODE_2K", TRANSMISSION_MODE_2K },
{ "TRANSMISSION_MODE_8K", TRANSMISSION_MODE_8K },
{ "TRANSMISSION_MODE_AUTO", TRANSMISSION_MODE_AUTO }
};
#define LIST_SIZE(x) sizeof(x)/sizeof(Param)
static
int parse_param (int fd, const Param * plist, int list_size, int *param)
{
char c;
int character = 0;
int _index = 0;
while (1) {
if (read(fd, &c, 1) < 1)
return -1; /* EOF? */
if ((c == ':' || c == '\n')
&& plist->name[character] == '\0')
break;
while (toupper(c) != plist->name[character]) {
_index++;
plist++;
if (_index >= list_size) /* parse error, no valid */
return -2; /* parameter name found */
}
character++;
}
*param = plist->value;
return 0;
}
static
int parse_int(int fd, int *val)
{
char number[11]; /* 2^32 needs 10 digits... */
int character = 0;
while (1) {
if (read(fd, &number[character], 1) < 1)
return -1; /* EOF? */
if (number[character] == ':' || number[character] == '\n') {
number[character] = '\0';
break;
}
if (!isdigit(number[character]))
return -2; /* parse error, not a digit... */
character++;
if (character > 10) /* overflow, number too big */
return -3; /* to fit in 32 bit */
};
*val = strtol(number, NULL, 10);
return 0;
}
static
int find_channel(int fd, const char *channel)
{
int character = 0;
while (1) {
char c;
if (read(fd, &c, 1) < 1)
return -1; /* EOF! */
if ( '\n' == c ) /* start of line */
character = 0;
else if ( character >= 0 ) { /* we are in the namefield */
