Hello, I tried scanning with the 7201 changeset and I believe the results are better than the 7205 changeset. In the former case I get 2082 services on hotbird, in the latter 1722. I'll shortly send kernel logs for a failing transponder during scan. And something else: When I give to scan the parameter -o vdr it will not output the results after a complete scan. Regards Vagelis Vangelis Nonas wrote: > Hello, > > I attach the timing logs for changsets 7205 and 7201. The funny thing > is that when I use 7201 it does NOT have the problem with locking > when tuning, as it had before. I tried it 3 times, the third after a > full shutdown of the pc and having removed the power for a couple on > minutes. It is really strange. > > Anyway, both logs were taken with these commands: > > ../szap/szap -c channels.conf -r "bbc world" > ../szap/szap -c channels.conf -r "bbc prime" > ../szap/szap -c channels.conf -r "filmnet1" > > I'll check how scanning performs with 7201 and let you know > > Regards > Vagelis > > > Manu Abraham wrote: >> Vangelis Nonas wrote: >>> Thank you all for your help, >>> >>> With the latest changeset I can tune channels correctly. I tried vdr >>> and szap (from Manu). >>> >>> I dont know how to undo the last changesets and go back to 7200. >>> Please tell me how to do it and I'll get the timings. >> >> >> clone the multiproto tree >> >> from there, do a partial clone locally >> >> hg clone -r 7200 multiproto multiproto_7200 >> >> >>> I also tried to scan Hotbird and it seems that scanning is now >>> consistent when you scan the same transponder more than once. >>> >>> A full scan produced 1722 channels which is not bad, but it needs >>> improvement. There are about 2200 channels I think. >> >> If you can provide a log with verbose=5 for the channels which it >> doesn't >> scan it will be a bit more helpful. Will need the logs >> (/var/log/messages) >> to debug this as well. The module parameters the same for both the >> STB0899 and the STB6100 >> >>> I attach the log of the scan. It fails to scan certain transponders >>> and I believe (not 100% sure, but I did some testing) that this is >>> consistent across runs. >> >> The log is just the output of the scan utility, will need the output >> from >> the driver and a bit of thoughts. >> >> >> >> Regards, >> Manu >> >>> Regards >>> Vagelis >>> >>> >>> >>> Manu Abraham wrote: >>>> Manu Abraham wrote: >>>> >>>>> Artem Makhutov wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Sat, Feb 23, 2008 at 10:32:58PM +0100, Artem Makhutov wrote: >>>>>> >>>>>>> On Sun, Feb 24, 2008 at 01:29:31AM +0400, Manu Abraham wrote: >>>>>>> >>>>>>>> Are you sure that you got the top level 2 changes changeset >>>>>>>> 7204 and 7203 >>>>>>>> respectively ? >>>>>>>> >>>>>>> Oh, I only got 7203. Will try with 7204 in a few minutes. >>>>>>> >>>>>> Awesome! It fixed the problem: >>>>>> >>>>>> Try: 100 >>>>>> Failes: 0 >>>>>> Tunes: 100 >>>>>> >>>>>> Great job! >>>>>> >>>> >>>> Also, can you please do a benchmark in lock timings between >>>> changeset 7205 and 7200 ? >>>> >>>> The timing can be looked at by enabling the time stamps in the >>>> kernel config and >>>> looking at timestamps in the logs for start - stop (FE_HAS_LOCK) >>>> between the 2 >>>> changesets. >>>> >>>> Regards, >>>> Manu >>>> >>>> _______________________________________________ >>>> linux-dvb mailing list >>>> linux-dvb@xxxxxxxxxxx >>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >>>> >>>> >>>> >>> >> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
