Hey, good morning to all (well maybe good afternoon, night, here is 9:00am ;) ) I had been doing some tests this morning on XP and why I didn't made them before?. I think that I have two problems, first one is the signal quality, I have 65% of level and 98% of quality, 65% maybe the problem of the impossibility of tunning certain transponders, I had tried some of the problematic ones and the can't lock and scan on XP probrams like ProgDVB. So first thing I need to increase the signal level. Second, the incorrect vid&aid, really I don't know what is happening here, on XP never get wrong vid&aid, so this will not be a dish installation problem (I think). Well thats all form XP. Regarddddssss. 2008/8/30 Beth <beth.null@xxxxxxxxx>: > 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@xxxxxxxxx>: >> 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@xxxxxxxxx> 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@xxxxxxxxx > > 661 960 119 > > Sometimes something happens ... > --------------------------------------------------- > -- --------------------------------------------------- José Antonio Robles beth.null@xxxxxxxxx 661 960 119 Sometimes something happens ... --------------------------------------------------- _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
