On 11/29/06, Federico Quagliata <federico@xxxxxxxxxxxxx> wrote:
José Oliver Segura wrote:
> Does this mean some advance to see why some devices work fine
> with their native drivers/mediacenters/windows and not so well under
> linux? I experiment the same behaviour with my nova-t stick. Currently
> I'm trying to get an example of errors/signal for each
> channel/frequency, just to see if it can show me some kind of common
> factor about the group of channels that don't work 100% ok with linux,
> in order to see it gives some clue regarding this.
How are you proceeding in doing this? I can do the same so we could compare
the results.
Well, just in a simple way: I am trying to set up a simple perl
script that launches tzap for each of the channels in channels.conf,
wait enough to get some output (5-10 seconds) and gets data regarding
signal/unc/ber reported by tzap. Then it just writes it back to the
output and performs some basic statistics (i.e. mean of signal
strenght-ber-unc for each frequency?). That's what I'm planning to do.
It's not so "easy" because the perl script doesn't get the output from
tzap (buffering and pipes issue). But the basic idea could be like
that. I can e-mail you the script once I get it running, just to
compare your outputs and mine.
I'm thinking about doing that because, just by observation, I
see that channels with low frequencies show a little number of ber/unc
(in many cases, 0), and a signal of about 0x9../0xa..., and as the
frequency gets higher, ber/unc grow up and signal goes down (0x7...).
I'd blame for this my antenna (and so, I'm waiting fo the antenna guy
to come and review my installation), but the fact is that it works OK
under windows, and... The big tower that sends dvb-t (Collserola -
Barcelona - Spain) can be seen from my window, just a few kilometers
away... so... :(
> I've also e-mailed tech support@hauppauge in order to know if
> they could give me some hint about what their drivers/applications do
> and -seems- linux drivers doesn't do (as long as -it seems- that
> native hauppauge applications don't show up these kind of artifacts),
> but, as you could expect... no reply yet (I don't hope to get it, but
> that mail is something I must try, as "hauppauge" customer :) )
I have another update: I ran mplayer with debug on and this seems to be
interesting:
a bounch of
ts_parse: PID=###, Transport error: 1, CC_OK: no
and
ts_parse: PID=###, Transport error: 1, CC_OK: yes
I've no idea about what that could mean... but I'll try to run
mplayer also with debug, just to check if I get the same output. Did
you get it running directly mplayer with dvb://? Just let me know,
because my "personal dvb" is just a little perl script that uses
tzap/cat/mplayer and temporary files for mpeg data and pipes for
mplayer control, and maybe to get this debug output mplayer needs to
be "in control" of the dvb devices.
It would be great to get some input from hauppauge, but... you
know.. we're second class citizens :-)
Best,
Jose
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
