Re: [linux-dvb] extra switch for tzap

2007-08-05 Thread Christoph Pfister
Hi,

Am Freitag, 20. Juli 2007 12:37 schrieb P. van Gaans:
snip
 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

2007-07-22 Thread 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

___
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

2007-07-22 Thread Uwe Bugla
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

2007-07-22 Thread 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

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

2007-07-22 Thread Uwe Bugla
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

2007-07-22 Thread timecop
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

2007-07-22 Thread 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

-- 
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

2007-07-22 Thread Uwe Bugla
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

2007-07-22 Thread Nico Sabbi
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

2007-07-21 Thread Christophe Thommeret
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, problems with the scan utility: filter timeout pid appearing very often

2007-07-21 Thread Uwe Bugla
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

2007-07-20 Thread P. van Gaans

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] {channel name| -n channel_num} [-x]\n
-	   or: %s [-c conf_file]  -l\n\n;
+	   or: %s [-c 

Re: [linux-dvb] extra switch for tzap

2007-07-20 Thread Uwe Bugla
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

2007-07-20 Thread 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.)

-- 
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

2007-07-20 Thread Uwe Bugla
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

2007-07-20 Thread P. van Gaans
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

2007-07-20 Thread Christoph Pfister
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

2007-07-20 Thread Uwe Bugla
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

2007-07-20 Thread Uwe Bugla
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-07-19 Thread Uwe Bugla
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

2007-07-19 Thread Christophe Thommeret
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

2007-07-19 Thread Uwe Bugla
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
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 have offered any kind of help for improving the (next generation)
  driver for my specific card, which you can download here:
  http://www.thadathil.net. It's name is cx878.
  

Re: [linux-dvb] extra switch for tzap

2007-07-18 Thread Luca Olivetti
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


Re: [linux-dvb] extra switch for tzap

2007-07-18 Thread Uwe Bugla
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

2007-07-18 Thread Julian
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

2007-07-18 Thread Christophe Thommeret
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

2007-07-18 Thread Christoph Pfister
Am Mittwoch, 18. Juli 2007 11:44 schrieb Uwe Bugla:
snip
 - equally for tzap, czap, szap and femon?

You should first check whether somebody intends to pick it up ...

snip

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

2007-07-18 Thread Uwe Bugla
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:
  snip
 
   - 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.

  snip
 
  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

2007-07-18 Thread Christophe Thommeret
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

2007-07-18 Thread Uwe Bugla
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

2007-07-18 Thread Uwe Bugla
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

2007-07-18 Thread P. van Gaans
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

2007-07-18 Thread timecop
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

2007-07-18 Thread hermann pitton
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

2007-07-18 Thread timecop
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

2007-07-18 Thread hermann pitton
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