[linux-dvb] Skystar HD2 (device don't stream data).

Beth beth.null at gmail.com
Sat Aug 30 01:34:11 CEST 2008


Hi barry, I am finally at home, umm home sweet home, how are you?

I had made some of the "to-do" things:

First, I added the channels:

Das Erste:11836:h:0:27500:101:102:28106:0
Bayerisches FS Sued:11836:h:0:27500:201:202:28107:0
hr-fernsehen:11836:h:0:27500:301:302:28108:0
Bayerisches FS Nord:11836:h:0:27500:201:202:28110:0
WDR Koeln:11836:h:0:27500:601:602:28111:0
BR-alpha*:11836:h:0:27500:701:702:28112:0
SWR Fernsehen BW:11836:h:0:27500:801:802:28113:0

And I get a strange behavior, that remembers me the two problems you
said: dish installation or driver installation, that was the problem:

I was trying to tune the channels and I had the following pattern, one
time it works and one time didn't works alternatively, yes, I can tune
and see the channels each time I try it, and the next I can't. After
that I realized that this wasn't the problem, the problem was the time
between calls to szap2, If I wait less than 3 seconds more and less, I
get this behavior, if I wait 4 or more szap lock the frontend
successfully. Sometimes this time interval is bigger, or needs more
szap2 calls to catch the channel.

I realized too something in the /var/log/messages file, if the channel
is successfully tunned I get the following output:


Aug 30 01:04:43 nemesis kernel: [10520.275555] newfec_to_oldfec:
Unsupported FEC 9
Aug 30 01:04:43 nemesis kernel: [10520.275563] dvb_frontend_ioctl:
FESTATE_RETUNE: fepriv->state=2
Aug 30 01:04:43 nemesis kernel: [10520.275598] mantis start feed & dma
Aug 30 01:04:43 nemesis kernel: [10520.299097] stb6100_set_bandwidth:
Bandwidth=61262500
Aug 30 01:04:43 nemesis kernel: [10520.303361] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:04:43 nemesis kernel: [10520.326053] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:04:43 nemesis kernel: [10520.390307] stb6100_set_frequency:
Frequency=1236000
Aug 30 01:04:43 nemesis kernel: [10520.394568] stb6100_get_frequency:
Frequency=1235988
Aug 30 01:04:43 nemesis kernel: [10520.406471] stb6100_get_bandwidth:
Bandwidth=62000000

And stays here until I stop szap2, and I get:

Aug 30 01:04:47 nemesis kernel: [10524.580406] mantis stop feed and dma

But if the channels isn't tunned I get:

Aug 30 01:06:03 nemesis kernel: [10600.603748] newfec_to_oldfec:
Unsupported FEC 9
Aug 30 01:06:03 nemesis kernel: [10600.603754] dvb_frontend_ioctl:
FESTATE_RETUNE: fepriv->state=2
Aug 30 01:06:03 nemesis kernel: [10600.603990] mantis start feed & dma
Aug 30 01:06:03 nemesis kernel: [10600.648523] stb6100_set_bandwidth:
Bandwidth=61262500
Aug 30 01:06:03 nemesis kernel: [10600.652720] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:06:03 nemesis kernel: [10600.678113] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:06:03 nemesis kernel: [10600.744773] stb6100_set_frequency:
Frequency=1236000
Aug 30 01:06:03 nemesis kernel: [10600.748951] stb6100_get_frequency:
Frequency=1235988
Aug 30 01:06:03 nemesis kernel: [10600.760337] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:06:04 nemesis kernel: [10601.576304] stb6100_set_bandwidth:
Bandwidth=61262500
Aug 30 01:06:04 nemesis kernel: [10601.580481] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:06:04 nemesis kernel: [10601.603144] stb6100_get_bandwidth:
Bandwidth=62000000
Aug 30 01:06:04 nemesis kernel: [10601.667229] stb6100_set_frequency:
Frequency=1236000
Aug 30 01:06:04 nemesis kernel: [10601.671408] stb6100_get_frequency:
Frequency=1235988
Aug 30 01:06:04 nemesis kernel: [10601.684111] stb6100_get_bandwidth:
Bandwidth=62000000

...

And repeat over and over util I break the szap2 program, getting the same


Aug 30 01:06:08 nemesis kernel: [10605.094697] mantis stop feed and dma

This happens with your channels, but if I try our beloved TV GALICIA,
I never get this behaviour, well, in some occasion I get two repeats
of the loop :

Aug 30 01:08:08 nemesis kernel: [10725.129081] newfec_to_oldfec:
Unsupported FEC 9
Aug 30 01:08:08 nemesis kernel: [10725.129088] dvb_frontend_ioctl:
FESTATE_RETUNE: fepriv->state=2
Aug 30 01:08:08 nemesis kernel: [10725.135534] mantis start feed & dma
Aug 30 01:08:08 nemesis kernel: [10725.152567] stb6100_set_bandwidth:
Bandwidth=51610000
Aug 30 01:08:08 nemesis kernel: [10725.156950] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:08 nemesis kernel: [10725.179650] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:08 nemesis kernel: [10725.243778] stb6100_set_frequency:
Frequency=1935000
Aug 30 01:08:08 nemesis kernel: [10725.247950] stb6100_get_frequency:
Frequency=1934982
Aug 30 01:08:08 nemesis kernel: [10725.259936] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:09 nemesis kernel: [10726.119567] stb6100_set_bandwidth:
Bandwidth=51610000
Aug 30 01:08:09 nemesis kernel: [10726.123741] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:09 nemesis kernel: [10726.146308] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:09 nemesis kernel: [10726.210778] stb6100_set_frequency:
Frequency=1935000
Aug 30 01:08:09 nemesis kernel: [10726.214952] stb6100_get_frequency:
Frequency=1934982
Aug 30 01:08:09 nemesis kernel: [10726.226934] stb6100_get_bandwidth:
Bandwidth=52000000
Aug 30 01:08:14 nemesis kernel: [10731.430950] mantis stop feed and dma

But finally it works.

It seems that I had problems with certain channels, and I think that
it would be a dish or driver problem.

Next I had made the changes to the scan.c following your code, and
launch the scan_test, having the same problems, the same scanning
time, and the same :0:0: problems. :(

The file http://sites.google.com/site/bethnull/Home/scan_test_second_try.tgz?attredirects=0
had the test (I was a bit impatient and there are only 3 scans).

And dvbtune, dammit, or it doesnt works for me or I am not using it correctly:

dvbtune -m -f 11685000 -p v -s 22000 -v 167 -a 108

Using DVB card "STB0899 Multistandard"
tuning DVB-S to L-Band:0, Pol:V Srate=22000000, 22kHz=off
polling....
Getting frontend event
FE_STATUS:
polling....
polling....

I am pooolliiingg youuuuuu, and I needddd to sleeppppp, :D,

I was trying that a friend of mine with a satellite spectrum analyzer
comes to my house and check the installation, but with my cheap and
inaccurate satellite finder I think that I can't do anything more.

Is there another way to see the signal level and noise?

Well is late, more tomorrow, good night barry (and everyone over
there), see you ;)

2008/8/27 barry bouwsma <free_beer_for_all at yahoo.com>:
> I finally knocked over the beer bottle long enough to try
> and make sense of why `scan' sometimes fails for me in the
> same way it fails for Beth.
>
> I get immediate signal lock on all Astra 19E2 DVB-S transponders
> and from them, when `scan' behaves today, I'm getting 1421
> received services, taking slightly over 5 minutes when using
> the `Astra SDT' frequency as the seed.
>
> In general, I should never see the word `timeout' in the
> stderr output when running `scan -v'.  When my `scan' has
> been misbehaving and delivering PIDs of 0 and ghost services,
> I see these timeouts, and plenty of them.
>
> After several hacks to `scan' to try and get it to read and
> discard data, without perfect success, I've had three
> consecutive scans without the problems, that in my last scan,
> resulted in three transponders with bad data.  More on that
> soon.
>
> I don't know what I'm doing, and have no clue what `scan' is
> doing, nor what the underlying API and driver are doing, so my
> hacks are certainly wrong.  Also, I don't see these problems
> with two other DVB-S cards I have, only with my newest one.
>
> At best, this is a workaround in `scan' and not a fix.
>
>
>
> I ran `scan -v -v -v -v -v v- v-v v-v-v' (you get the idea)
> fed by the Astra SDT frequency.  What do you know, the
> first frequency scanned had problems, allowing me to repeat
> the scan simply and get correct results.
>
> Here's the basics of the `diff' of stderr of these results...
>
> --- /tmp/success        2008-08-27 16:26:08.244916390 +0200
> +++ /tmp/parse  2008-08-27 14:30:30.264896960 +0200
> @@ -18,31 +18,31 @@
>  update_poll_fds:1418: poll fd 6
>  update_poll_fds:1418: poll fd 5
>  update_poll_fds:1418: poll fd 4
> -parse_section:1257: pid 0x00 tid 0x00 table_id_ext 0x0454, 0/0 (version 15)
> +parse_section:1257: pid 0x00 tid 0x00 table_id_ext 0x0004, 0/0 (version 16)
>  PAT
> -add_filter:1498: add filter pid 0x002a
> -start_filter:1438: start filter pid 0x002a table_id 0x02
> +add_filter:1498: add filter pid 0x0067
> +start_filter:1438: start filter pid 0x0067 table_id 0x02
>  update_poll_fds:1418: poll fd 7
>  update_poll_fds:1418: poll fd 6
>  update_poll_fds:1418: poll fd 5
>  update_poll_fds:1418: poll fd 4
> -add_filter:1498: add filter pid 0x0034
> -start_filter:1438: start filter pid 0x0034 table_id 0x02
> +add_filter:1498: add filter pid 0x006c
> +start_filter:1438: start filter pid 0x006c table_id 0x02
>
> And on it goes.
>
> The incorrect lines above are those preceded by `+'; notably,
> the PID 0 (PAT) table_id_ext is different, as are the PIDs to
> be found within.
>
> However the correct SDT is read, which is the next filter (PID 0x11)
> to be added.  In the code of scan.c (my line numbers will be off)...
>
>   1971 static void scan_tp_dvb (void)
>   1972 {
>   1973         struct section_buf s0;
>   1974         struct section_buf s1;
>   1975         struct section_buf s2;
>   1976         struct section_buf s3;
>   1977
>   1978         /**
>   1979          *  filter timeouts > min repetition rates specified in ETR211
>   1980          */
>   1981         setup_filter (&s0, demux_devname, 0x00, 0x00, -1, 1, 0, 5); /* P
>   1981 AT */
>   1982         setup_filter (&s1, demux_devname, 0x11, 0x42, -1, 1, 0, 5); /* S
>   1982 DT */
>   1983
>   1984         add_filter (&s0);
>   1985         add_filter (&s1);
>
>
> What happens for me is that with every twenty or so attempts
> to tune a new transponder with `scan', even at the start of a
> scan, the first filter set up for PID 0 delivers the PAT table
> from the previously-tuned DVB-S transponder.
>
> However, the second filter, the SDT table, delivers the correct
> data.  The following filters added are based on the incorrect
> PAT PIDs, and therefore timeout without receiving anything.  The
> SDT entries don't get filled out by matching PIDs from the PAT
> and they too appear in the result without the proper PIDs, but
> with the correct names from the SDT.
>
>
> This has not been observed to be a problem with two other cards
> I have, ever -- only with one card, the Opera DVB-USB tuner, and
> at the time of my tests, on lightly-hacked 2.6.27-rc4 as of 23.Aug
> (and had been present on all previous kernels I tested).
>
> My attempt to read and discard and re-read from these PIDs was a
> half-success (I got valid PIDs for all proper services, but I still
> saw leftovers).  My latest hack is simply adding these filters,
> promptly deleting them, and adding them again, and so far has not
> failed, but more testing is needed.
>
> A few more scans have revealed no problems, and my 'net connectivity
> has disappeared, preventing me from verifying the source for other
> flavours of `scan'.  So I submit this patch from my hacked scan.c:
>
>
> @@ -1842,15 +1981,39 @@ static void scan_tp_dvb (void)
>        setup_filter (&s0, demux_devname, 0x00, 0x00, -1, 1, 0, 5); /* PAT */
>        setup_filter (&s1, demux_devname, 0x11, 0x42, -1, 1, 0, 5); /* SDT */
>
>        add_filter (&s0);
>        add_filter (&s1);
>
> +/* XXX HACK  sometimes, filter s0 gets stale data, while the SDT filter
> + * gets the correct data.  Then nothing gets proper PIDs.  what to do...
> + * try removing the filters, and re-adding... */
> +
> +       remove_filter (&s0);
> +       remove_filter (&s1);
> +
> +#if 0  /* this partly helped, but not completely  */
> +//     do {
> +//             read_filters ();
> +//     } while (!(list_empty(&running_filters) &&
> +//                list_empty(&waiting_filters)));
> +#endif
> +
> +       setup_filter (&s0, demux_devname, 0x00, 0x00, -1, 1, 0, 5); /* PAT */
> +       setup_filter (&s1, demux_devname, 0x11, 0x42, -1, 1, 0, 5); /* SDT */
> +
> +       add_filter (&s0);
> +       add_filter (&s1);
> +
> +/* XXX  */
> +
>        if (!current_tp_only || output_format != OUTPUT_PIDS) {
> +             if (!no_nits) {
>                setup_filter (&s2, demux_devname, 0x10, 0x40, -1, 1, 0, 15); /* NIT */
>                add_filter (&s2);
> +             }
>                if (get_other_nits) {
>                        /* get NIT-others
>                         * Note: There is more than one NIT-other: one per
>                         * network, separated by the network_id.
>                         */
>                         setup_filter (&s3, demux_devname, 0x10, 0x41, -1, 1, 1, 15);
>
>
>
> You certainly need to apply this by hand; in particular,
> you don't want to apply past the last `XXX', the !no_nits
> test is a local hack I have.
>
> In my script I've eliminated the `sleep' that was supposed to
> clear out the old data, and a full scan of all 120 transponders
> (including non-DVB-S) takes me less than 6 1/2 min, and only
> occasionally results in a random `timeout' message from a single
> service, that is probably momentarily missing the needed PIDs,
> as it's the same in some four successful scans.
>
> It turns out I had already downloaded the DVB-S2-aware `scan', and
> the code above seems to be pretty much identical.
>
>
>
> Beth, as you know, you suffer two problems --
>
> * services with 0:0 PIDs that should be something else, and
>  related to this, extra services that should not be there;
>
> * Difficulty tuning certain transponders, either a driver
>  issue if your other OSen work well, or perhaps a dish issue.
>
> The first of these problems *may* be `fixed' (ha) by the hack
> above.  Please try it; I don't think it will break anything.
> In any case, you should be able to get correct PIDs for TVGalicia
> and others with every one of repeated scans -- at least, it has
> worked for me.
>
>
> With my last scan, I saw 295 services which had 0:0 PIDs, out
> of the 1421 DVB-S services.  Most of these are data services.
> Some of these aren't, and may be different at a different time
> of day or with a different `scan' program...
>
> ### SCRAMBLED!!!  ###  NOT RUNNING!  #Blue Hustler:10920:h:1:22000:0:0:20353
> Pr0n that only is shown at night, at which time a different
> service on this transponder gets 0:0 PIDs as it stops running
> for the evening.
>
> ##  NOT RUNNING!  #.:12246:v:1:27500:0:0:10128
> I really hate the way APS manages their transponders, keeping
> off-the-air programs around, or recycling service IDs so that
> Volksmusik TV is replaced by pr0n and I have to hastily reprogram
> all the receivers I installed for grandparents.  Some receivers
> will show these status not-running channels and I can't delete
> them and have them stay deleted.  At some time these may return
> as a new service, pr0n, most likely.  Is it okay if I rant about
> APS here?
>
> NDR FS HH+:12421:h:1:27500:0:0:28325
> Placeholders from recently discontinued programs to allow EPG
> info about the frequency change to appear; will, like all the
> others, disappear within some weeks.
>
> Radio 4 Surround:12515:h:1:22000:0:0:4047
> Like Oe1 DD, an AC3-only audio service, while `scan' only prints
> the primary audio PID for me.
>
> ### SCRAMBLED!!!  #BiB:12574:h:1:22000:0:0:5029
> This gave me timeouts the last few scans; used to have proper PIDs
>
> ### SCRAMBLED!!!  #RADIOROPA-H<F6>rbuch 2:12603:h:1:22000:0:0:6002
> No longer broadcasting; some other services should start here
>
> ### SCRAMBLED!!!  ###  NOT RUNNING!  #Bundesliga 9:12662:h:1:22000:0:0:13110
> Again, sometimes you'll see it, sometimes not.
>
>
> Most of what you'll see will be data services, and in general,
> if you can receive all active transponders from 19E2, you should
> see somewhat less than 300 PIDs of 0:0 at the time I write this.
> That's about one data service out of every five services.
>
>
>
> --- On Tue, 8/26/08, Beth <beth.null at gmail.com> wrote:
>
>> > a different card, with the same `scan' that works
>> fine with two
>> > other cards on a different machine (much older
>> kernel).
>>
>> Can I try another scan? from where?
>
> I don't think so, as your card supports DVB-S2 -- but, as I
> don't have hands-on experience with any of those cards and
> related drivers, I don't even have an overview.
>
> At best, a normal `scan' would give you only DVB-S results;
> at worst, you wouldn't see anything...
>
>
>
> barry bouwsma
>
>
>
>
>



-- 
---------------------------------------------------
José Antonio Robles

beth.null at gmail.com

661 960 119

Sometimes something happens ...
---------------------------------------------------



More information about the linux-dvb mailing list