| Message ID | 497F78E9.9090608@gmail.com (mailing list archive) |
|---|---|
| State | RFC |
| Headers | show |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Manu Abraham wrote: > Alex Betis wrote: >> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham <abraham.manu@gmail.com>wrote: >> >>>> Hmm OK, but is there by any chance a fix for those issues somewhere or >>>> in the pipe at least? I am willing to test (as I already offered), I >>>> can compile the drivers, spread printk or whatever else is needed to >>>> get useful reports. Let me know if I can help sort this problem. BTW in >>>> my case it is DVB-S2 30000 SR and FEC 5/6. >>> It was quite not appreciable on my part to provide a fix or reply in >>> time nor spend much time on it earlier, but that said i was quite >>> stuck up with some other things. >>> >>> Can you please pull a copy of the multiproto tree >>> http://jusst.de/hg/multiproto or the v4l-dvb tree from >>> http://jusst.de/hg/v4l-dvb >>> >>> and apply the following patch and comment what your result is ? >>> Before applying please do check whether you still have the issues. >> Manu, >> I've tried to increase those timers long ago when played around with my card >> (Twinhan 1041) and scan utility. >> I must say that I've concentrated mostly on DVB-S channels that wasn't >> always locking. >> I didn't notice much improvements. The thing that did help was increasing >> the resolution of scan zigzags. > > With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. > Most likely you haven't tried that change. > >> I've sent a patch on that ML and people were happy with the results. > > I did look at your patch, but that was completely against the tuning > algorithm. > > [..] > >> I believe DVB-S2 lock suffer from the same problem, but in that case the >> zigzag is done in the chip and not in the driver. > > Along with the patch i sent, does the attached patch help you in > anyway (This works out for DVB-S2 only)? > > > - From what I understand the driver still has some issues. Got feedback from another guy with Canal Digital in Norway that he has the same issues as me. Not sure if the diff was an attempt to fix the digital artefacts but I tried applying the diff manually on the source I grabbed from http://jusst.de/hg/v4l-dvb/ but did not notice any improvements or difference with the artefacts. Would any logs be helpful? If there is anything else I could try I'm willing to try it out. I appreciate your effort. Thanks. Jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkmHIuMACgkQpvOo+MDrK1H1wACggFIUgXQHcJxBhjCCGXtDLe44 b7EAn0VW7orjhEdbhyWgQhOITWopLxwg =dSFB -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham <abraham.manu@gmail.com> wrote: > Alex Betis wrote: >> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham <abraham.manu@gmail.com>wrote: >> >>>> Hmm OK, but is there by any chance a fix for those issues somewhere or >>>> in the pipe at least? I am willing to test (as I already offered), I >>>> can compile the drivers, spread printk or whatever else is needed to >>>> get useful reports. Let me know if I can help sort this problem. BTW in >>>> my case it is DVB-S2 30000 SR and FEC 5/6. >>> It was quite not appreciable on my part to provide a fix or reply in >>> time nor spend much time on it earlier, but that said i was quite >>> stuck up with some other things. >>> >>> Can you please pull a copy of the multiproto tree >>> http://jusst.de/hg/multiproto or the v4l-dvb tree from >>> http://jusst.de/hg/v4l-dvb >>> >>> and apply the following patch and comment what your result is ? >>> Before applying please do check whether you still have the issues. >> >> Manu, >> I've tried to increase those timers long ago when played around with my card >> (Twinhan 1041) and scan utility. >> I must say that I've concentrated mostly on DVB-S channels that wasn't >> always locking. >> I didn't notice much improvements. The thing that did help was increasing >> the resolution of scan zigzags. > > With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. > Most likely you haven't tried that change. > >> I've sent a patch on that ML and people were happy with the results. > > I did look at your patch, but that was completely against the tuning > algorithm. > > [..] > >> I believe DVB-S2 lock suffer from the same problem, but in that case the >> zigzag is done in the chip and not in the driver. > > Along with the patch i sent, does the attached patch help you in > anyway (This works out for DVB-S2 only)? > Manu, I've tried both multiproto branches you indicated above, *with* and *without* the patches you sent to the ML (fix_iterations.patch and increase timeout.patch) on this thread. Sadly, same behavior as S2API V4L-DVB current branch. No lock on 30000 3/4 channels. It achieves a 0.5 second jittery sound but no image. It seems the driver is struggling to correctly lock on that channel, but doesn't get there in time... Or maybe the hardware... Dunno... Channels like ASTRA HD+;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 PREMIERE HD,PREM HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 DISCOVERY HD,DISC HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 work just fine. But channels like National Geographic HD;National Geographic HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 MOV HD;MOV HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 Sport TV - HD;Sport TV - HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 RTP HD;RTP HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 TVCine 4 HD;TVCine 4 HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 Disney Cinemagic HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 Eurosport HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 or [0065];:12012:hC34M5S1:S30.0W:30000:4097:4098:4100:100:101:0:0:0 [0066];:12012:hC34M5S1:S30.0W:30000:4105:4106:4100:100:102:0:0:0 [0067];:12012:hC34M5S1:S30.0W:30000:4113:4114:4100:100:103:0:0:0 [0068];:12012:hC34M5S1:S30.0W:30000:4121:4122:4100:100:104:0:0:0 [0069];:12012:hC34M5S1:S30.0W:30000:4129:4130:4100:100:105:0:0:0 [006a];:12012:hC34M5S1:S30.0W:30000:4137:4138:4100:100:106:0:0:0 [006b];:12012:hC34M5S1:S30.0W:30000:4145:4146:4100:100:107:0:0:0 simply don't work. BTW, I think the channels above that don't work have a 0x0B stream indication. Satellite operators are misleading on the stream (h.222) when in fact they are h.264. Read that were on the ML. Don't know if it affects anything, but hey... I have to try everything! ;) I'm available to any tests necessary to fix this once and for all, if possible. Just let me know. Thanks for all your hard work. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 02.02.2009 18:43:33, Chris Silva a écrit : > On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham > <abraham.manu@gmail.com> > wrote: > > Alex Betis wrote: > >> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham > <abraham.manu@gmail.com>wrote: > >> > >>>> Hmm OK, but is there by any chance a fix for those issues > somewhere or > >>>> in the pipe at least? I am willing to test (as I already > offered), I > >>>> can compile the drivers, spread printk or whatever else is > needed > to > >>>> get useful reports. Let me know if I can help sort this problem. > BTW in > >>>> my case it is DVB-S2 30000 SR and FEC 5/6. > >>> It was quite not appreciable on my part to provide a fix or reply > in > >>> time nor spend much time on it earlier, but that said i was quite > >>> stuck up with some other things. > >>> > >>> Can you please pull a copy of the multiproto tree > >>> http://jusst.de/hg/multiproto or the v4l-dvb tree from > >>> http://jusst.de/hg/v4l-dvb > >>> > >>> and apply the following patch and comment what your result is ? > >>> Before applying please do check whether you still have the > issues. > >> > >> Manu, > >> I've tried to increase those timers long ago when played around > with my card > >> (Twinhan 1041) and scan utility. > >> I must say that I've concentrated mostly on DVB-S channels that > wasn't > >> always locking. > >> I didn't notice much improvements. The thing that did help was > increasing > >> the resolution of scan zigzags. > > > > With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. > > Most likely you haven't tried that change. > > > >> I've sent a patch on that ML and people were happy with the > results. > > > > I did look at your patch, but that was completely against the > tuning > > algorithm. > > > > [..] > > > >> I believe DVB-S2 lock suffer from the same problem, but in that > case the > >> zigzag is done in the chip and not in the driver. > > > > Along with the patch i sent, does the attached patch help you in > > anyway (This works out for DVB-S2 only)? > > > > Manu, > > I've tried both multiproto branches you indicated above, *with* and > *without* the patches you sent to the ML (fix_iterations.patch and > increase timeout.patch) on this thread. > Sadly, same behavior as S2API V4L-DVB current branch. No lock on > 30000 > 3/4 channels. It achieves a 0.5 second jittery sound but no image. It > seems the driver is struggling to correctly lock on that channel, but > doesn't get there in time... Or maybe the hardware... Dunno... > > Channels like > > ASTRA HD > +;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 > PREMIERE HD,PREM > HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 > DISCOVERY HD,DISC > HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 > > work just fine. > > But channels like > > National Geographic HD;National Geographic > HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 > MOV HD;MOV > HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 > Sport TV - HD;Sport TV - > HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 > RTP HD;RTP > HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 > TVCine 4 HD;TVCine 4 > HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 > Disney Cinemagic > HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 > Eurosport > HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 > > or > > [0065];:12012:hC34M5S1:S30.0W:30000:4097:4098:4100:100:101:0:0:0 > [0066];:12012:hC34M5S1:S30.0W:30000:4105:4106:4100:100:102:0:0:0 > [0067];:12012:hC34M5S1:S30.0W:30000:4113:4114:4100:100:103:0:0:0 > [0068];:12012:hC34M5S1:S30.0W:30000:4121:4122:4100:100:104:0:0:0 > [0069];:12012:hC34M5S1:S30.0W:30000:4129:4130:4100:100:105:0:0:0 > [006a];:12012:hC34M5S1:S30.0W:30000:4137:4138:4100:100:106:0:0:0 > [006b];:12012:hC34M5S1:S30.0W:30000:4145:4146:4100:100:107:0:0:0 > > simply don't work. > > BTW, I think the channels above that don't work have a 0x0B stream > indication. Satellite operators are misleading on the stream (h.222) > when in fact they are h.264. Read that were on the ML. Don't know if > it affects anything, but hey... I have to try everything! ;) > > I'm available to any tests necessary to fix this once and for all, if > possible. Could I suggest something (probably stupid): I think that the TT 3650 is the same card but using USB, right (I mean it uses the stb0899/ stb6100 chips also)? So if someone could sniff the usb transactions during a successfull lock on a problematic channel (using windows then), we could see what is different. I do not have neither Windows, neither this card, but a good soul could help us here. Manu, is that sensible? Bye Manu (the other one ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 02.02.2009 18:43:33, Chris Silva a écrit : > On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham > <abraham.manu@gmail.com> > wrote: > > Alex Betis wrote: > >> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham > <abraham.manu@gmail.com>wrote: > >> > >>>> Hmm OK, but is there by any chance a fix for those issues > somewhere or > >>>> in the pipe at least? I am willing to test (as I already > offered), I > >>>> can compile the drivers, spread printk or whatever else is > needed > to > >>>> get useful reports. Let me know if I can help sort this problem. > BTW in > >>>> my case it is DVB-S2 30000 SR and FEC 5/6. > >>> It was quite not appreciable on my part to provide a fix or reply > in > >>> time nor spend much time on it earlier, but that said i was quite > >>> stuck up with some other things. > >>> > >>> Can you please pull a copy of the multiproto tree > >>> http://jusst.de/hg/multiproto or the v4l-dvb tree from > >>> http://jusst.de/hg/v4l-dvb > >>> > >>> and apply the following patch and comment what your result is ? > >>> Before applying please do check whether you still have the > issues. > >> > >> Manu, > >> I've tried to increase those timers long ago when played around > with my card > >> (Twinhan 1041) and scan utility. > >> I must say that I've concentrated mostly on DVB-S channels that > wasn't > >> always locking. > >> I didn't notice much improvements. The thing that did help was > increasing > >> the resolution of scan zigzags. > > > > With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. > > Most likely you haven't tried that change. > > > >> I've sent a patch on that ML and people were happy with the > results. > > > > I did look at your patch, but that was completely against the > tuning > > algorithm. > > > > [..] > > > >> I believe DVB-S2 lock suffer from the same problem, but in that > case the > >> zigzag is done in the chip and not in the driver. > > > > Along with the patch i sent, does the attached patch help you in > > anyway (This works out for DVB-S2 only)? > > > > Manu, > > I've tried both multiproto branches you indicated above, *with* and > *without* the patches you sent to the ML (fix_iterations.patch and > increase timeout.patch) on this thread. > Sadly, same behavior as S2API V4L-DVB current branch. No lock on > 30000 > 3/4 channels. It achieves a 0.5 second jittery sound but no image. It > seems the driver is struggling to correctly lock on that channel, but > doesn't get there in time... Or maybe the hardware... Dunno... > > Channels like > > ASTRA HD > +;BetaDigital:11914:hC910M2O35S1:S19.2E:27500:1279=27:0;1283=deu:0:0:131:133:6:0 > PREMIERE HD,PREM > HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:767=27:0;771=deu,772=eng:32:1837,1833,1834,9C4:129:133:6:0 > DISCOVERY HD,DISC > HD;PREMIERE:11914:hC910M2O35S1:S19.2E:27500:1023=27:0;1027=deu:32:1837,1833,1834,9C4:130:133:6 > > work just fine. > > But channels like > > National Geographic HD;National Geographic > HD:11731:vC34M5O25S1:S30.0W:29000:6496=27:6497:0:1802:943:54:47:0 > MOV HD;MOV > HD:11731:vC34M5O25S1:S30.0W:29000:6512=27:6513=por:0:1802:944:54:47:0 > Sport TV - HD;Sport TV - > HD:11731:vC34M5O25S1:S30.0W:29000:6528=27:6529=por:0:1802:945:54:47:0 > RTP HD;RTP > HD:11731:vC34M5O25S1:S30.0W:29000:6544=27:6545:0:1802:946:54:47:0 > TVCine 4 HD;TVCine 4 > HD:11731:vC34M5O25S1:S30.0W:29000:6560=27:6561:0:1802:947:54:47:0 > Disney Cinemagic > HD:11731:vC34M5O25S1:S30.0W:29000:6576=27:6577=por:0:1802:948:54:47:0 > Eurosport > HD:11731:vC34M5O25S1:S30.0W:29000:6592=27:6593=por:0:1802:949:54:47:0 > > or > > [0065];:12012:hC34M5S1:S30.0W:30000:4097:4098:4100:100:101:0:0:0 > [0066];:12012:hC34M5S1:S30.0W:30000:4105:4106:4100:100:102:0:0:0 > [0067];:12012:hC34M5S1:S30.0W:30000:4113:4114:4100:100:103:0:0:0 > [0068];:12012:hC34M5S1:S30.0W:30000:4121:4122:4100:100:104:0:0:0 > [0069];:12012:hC34M5S1:S30.0W:30000:4129:4130:4100:100:105:0:0:0 > [006a];:12012:hC34M5S1:S30.0W:30000:4137:4138:4100:100:106:0:0:0 > [006b];:12012:hC34M5S1:S30.0W:30000:4145:4146:4100:100:107:0:0:0 > > simply don't work. > > BTW, I think the channels above that don't work have a 0x0B stream > indication. Satellite operators are misleading on the stream (h.222) > when in fact they are h.264. Read that were on the ML. Don't know if > it affects anything, but hey... I have to try everything! ;) > > I'm available to any tests necessary to fix this once and for all, if > possible. Could I suggest something (probably stupid): I think that the TT 3650 is the same card but using USB, right (I mean it uses the stb0899/ stb6100 chips also)? So if someone could sniff the usb transactions during a successfull lock on a problematic channel (using windows then), we could see what is different. I do not have neither Windows, neither this card, but a good soul could help us here. Manu, is that sensible? Bye Manu (the other one ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Manu wrote: > Le 02.02.2009 18:43:33, Chris Silva a écrit : >> On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham >> <abraham.manu@gmail.com> >> wrote: >>> Alex Betis wrote: >>>> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham >> <abraham.manu@gmail.com>wrote: >>>>>> Hmm OK, but is there by any chance a fix for those issues >> somewhere or >>>>>> in the pipe at least? I am willing to test (as I already >> offered), I >>>>>> can compile the drivers, spread printk or whatever else is >> needed >> to >>>>>> get useful reports. Let me know if I can help sort this problem. >> BTW in >>>>>> my case it is DVB-S2 30000 SR and FEC 5/6. >>>>> It was quite not appreciable on my part to provide a fix or reply >> in >>>>> time nor spend much time on it earlier, but that said i was quite >>>>> stuck up with some other things. >>>>> >>>>> Can you please pull a copy of the multiproto tree >>>>> http://jusst.de/hg/multiproto or the v4l-dvb tree from >>>>> http://jusst.de/hg/v4l-dvb >>>>> >>>>> and apply the following patch and comment what your result is ? >>>>> Before applying please do check whether you still have the >> issues. >>>> Manu, >>>> I've tried to increase those timers long ago when played around >> with my card >>>> (Twinhan 1041) and scan utility. >>>> I must say that I've concentrated mostly on DVB-S channels that >> wasn't >>>> always locking. >>>> I didn't notice much improvements. The thing that did help was >> increasing >>>> the resolution of scan zigzags. >>> With regards to the zig-zag, one bug is fixed in the v4l-dvb tree. >>> Most likely you haven't tried that change. >>> >>>> I've sent a patch on that ML and people were happy with the >> results. >>> I did look at your patch, but that was completely against the >> tuning >>> algorithm. >>> >>> [..] >>> >>>> I believe DVB-S2 lock suffer from the same problem, but in that >> case the >>>> zigzag is done in the chip and not in the driver. >>> Along with the patch i sent, does the attached patch help you in >>> anyway (This works out for DVB-S2 only)? >>> >> Manu, >> >> I've tried both multiproto branches you indicated above, *with* and >> *without* the patches you sent to the ML (fix_iterations.patch and >> increase timeout.patch) on this thread. >> Sadly, same behavior as S2API V4L-DVB current branch. No lock on >> 30000 >> 3/4 channels. It achieves a 0.5 second jittery sound but no image. It >> seems the driver is struggling to correctly lock on that channel, but >> doesn't get there in time... Or maybe the hardware... Dunno... Can you please send me a complete trace with the stb6100 and stb0899 modules loaded with verbose=5 for the 30MSPS transponder what you are trying ? One simple szap would be enough (no scan please) based on the http://jusst.de/hg/v4l-dvb tree. Before you start testing, start clean from a cold boot after a powerdown. This makes it a bit more easier identify things. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le 05.02.2009 19:50:18, Manu Abraham a écrit : > Manu wrote: > > Le 02.02.2009 18:43:33, Chris Silva a écrit : > >> On Tue, Jan 27, 2009 at 9:13 PM, Manu Abraham > >> <abraham.manu@gmail.com> > >> wrote: > >>> Alex Betis wrote: > >>>> On Tue, Jan 27, 2009 at 9:56 PM, Manu Abraham > >> <abraham.manu@gmail.com>wrote: > >>>>>> Hmm OK, but is there by any chance a fix for those issues > >> somewhere or > >>>>>> in the pipe at least? I am willing to test (as I already > >> offered), I > >>>>>> can compile the drivers, spread printk or whatever else is > >> needed > >> to > >>>>>> get useful reports. Let me know if I can help sort this > problem. > >> BTW in > >>>>>> my case it is DVB-S2 30000 SR and FEC 5/6. > >>>>> It was quite not appreciable on my part to provide a fix or > reply > >> in > >>>>> time nor spend much time on it earlier, but that said i was > quite > >>>>> stuck up with some other things. > >>>>> > >>>>> Can you please pull a copy of the multiproto tree > >>>>> http://jusst.de/hg/multiproto or the v4l-dvb tree from > >>>>> http://jusst.de/hg/v4l-dvb > >>>>> > >>>>> and apply the following patch and comment what your result is ? > >>>>> Before applying please do check whether you still have the > >> issues. > >>>> Manu, > >>>> I've tried to increase those timers long ago when played around > >> with my card > >>>> (Twinhan 1041) and scan utility. > >>>> I must say that I've concentrated mostly on DVB-S channels that > >> wasn't > >>>> always locking. > >>>> I didn't notice much improvements. The thing that did help was > >> increasing > >>>> the resolution of scan zigzags. > >>> With regards to the zig-zag, one bug is fixed in the v4l-dvb > tree. > >>> Most likely you haven't tried that change. > >>> > >>>> I've sent a patch on that ML and people were happy with the > >> results. > >>> I did look at your patch, but that was completely against the > >> tuning > >>> algorithm. > >>> > >>> [..] > >>> > >>>> I believe DVB-S2 lock suffer from the same problem, but in that > >> case the > >>>> zigzag is done in the chip and not in the driver. > >>> Along with the patch i sent, does the attached patch help you in > >>> anyway (This works out for DVB-S2 only)? > >>> > >> Manu, > >> > >> I've tried both multiproto branches you indicated above, *with* > and > >> *without* the patches you sent to the ML (fix_iterations.patch and > >> increase timeout.patch) on this thread. > >> Sadly, same behavior as S2API V4L-DVB current branch. No lock on > >> 30000 > >> 3/4 channels. It achieves a 0.5 second jittery sound but no image. > It > >> seems the driver is struggling to correctly lock on that channel, > but > >> doesn't get there in time... Or maybe the hardware... Dunno... > > Can you please send me a complete trace with the stb6100 and stb0899 > modules loaded with verbose=5 for the 30MSPS transponder what you > are trying ? One simple szap would be enough (no scan please) based > on the http://jusst.de/hg/v4l-dvb tree. > > Before you start testing, start clean from a cold boot after a > powerdown. This makes it a bit more easier identify things. OK I did just that with latest multiproto on a 11495 MHz trnaposnder, DVB-S2, 30MS/s, FEC 5/6 which works using the provider's STB . I put the log in attachement. You will observe a lock is acquired really briefly and then nothing. Obtained using: szap2 -t 2 I hope this can give you some data. Let me know if you need more info (like putting some more printksin the source). Bye Manu
On Fri, Feb 6, 2009 at 3:22 PM, Manu <eallaud@gmail.com> wrote: >> Can you please send me a complete trace with the stb6100 and stb0899 >> modules loaded with verbose=5 for the 30MSPS transponder what you >> are trying ? One simple szap would be enough (no scan please) based >> on the http://jusst.de/hg/v4l-dvb tree. >> >> Before you start testing, start clean from a cold boot after a >> powerdown. This makes it a bit more easier identify things. > > OK I did just that with latest multiproto on a 11495 MHz trnaposnder, > DVB-S2, 30MS/s, FEC 5/6 which works using the provider's STB . I put > the log in attachement. You will observe a lock is acquired really > briefly and then nothing. Obtained using: > szap2 -t 2 > I hope this can give you some data. Let me know if you need more info > (like putting some more printksin the source). > Bye > Manu > Sorry for the late reply, but the new list confuses the hell out of me and I missed this message, somehow... Attached is a log file with the results of dvb-apps/szap on a 30000 3/4 channel using a http://jusst.de/hg/v4l-dvb clean compile and cold boot as recommended. Also loaded stb6100 and stb0899 with verbose=5 Command line used and result: root@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -n 7 reading channels from file '/video/channels.conf' zapping to 7 '[006b]': sat 0, frequency = 12012 MHz H, symbolrate 30000000, vpid = 0x1031, apid = 0x1032 sid = 0x1004 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | [...] status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | After that szapping to that problematic channel, I tried a DVB-S channel, which locks without problems. root@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -H -n 33 reading channels from file '/video/channels.conf' zapping to 33 'FOX': sat 0, frequency = 11617 MHz V, symbolrate 27500000, vpid = 0x1b30, apid = 0x1b31 sid = 0x0000 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 49% | snr 0% | ber 0 | unc -2 | status 1e | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK Going to test your the same multiproto tree _with_ both patches you mentioned early on this thread. BTW, I can see all those channels just fine using a DM800 and the provider original decoder with my subscription card. I'm positive that dish/lnb/connections aren't the problem. Thanks for taking the time to address this particular issue. Chris
On Sat, Feb 14, 2009 at 10:34 PM, Chris Silva <2manybills@gmail.com> wrote: > On Fri, Feb 6, 2009 at 3:22 PM, Manu <eallaud@gmail.com> wrote: >>> Can you please send me a complete trace with the stb6100 and stb0899 >>> modules loaded with verbose=5 for the 30MSPS transponder what you >>> are trying ? One simple szap would be enough (no scan please) based >>> on the http://jusst.de/hg/v4l-dvb tree. >>> >>> Before you start testing, start clean from a cold boot after a >>> powerdown. This makes it a bit more easier identify things. >> >> OK I did just that with latest multiproto on a 11495 MHz trnaposnder, >> DVB-S2, 30MS/s, FEC 5/6 which works using the provider's STB . I put >> the log in attachement. You will observe a lock is acquired really >> briefly and then nothing. Obtained using: >> szap2 -t 2 >> I hope this can give you some data. Let me know if you need more info >> (like putting some more printksin the source). >> Bye >> Manu >> > > Sorry for the late reply, but the new list confuses the hell out of me > and I missed this message, somehow... > > Attached is a log file with the results of dvb-apps/szap on a 30000 > 3/4 channel using a http://jusst.de/hg/v4l-dvb clean compile and cold > boot as recommended. > > Also loaded stb6100 and stb0899 with verbose=5 > > Command line used and result: > > root@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c > /video/channels.conf -n 7 > reading channels from file '/video/channels.conf' > zapping to 7 '[006b]': > sat 0, frequency = 12012 MHz H, symbolrate 30000000, vpid = 0x1031, > apid = 0x1032 sid = 0x1004 > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | > status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | > [...] > status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | > status 00 | signal 7fb2 | snr 0000 | ber 00000000 | unc fffffffe | > > After that szapping to that problematic channel, I tried a DVB-S > channel, which locks without problems. > > root@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c > /video/channels.conf -H -n 33 > reading channels from file '/video/channels.conf' > zapping to 33 'FOX': > sat 0, frequency = 11617 MHz V, symbolrate 27500000, vpid = 0x1b30, > apid = 0x1b31 sid = 0x0000 > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > status 00 | signal 49% | snr 0% | ber 0 | unc -2 | > status 1e | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK > > Going to test your the same multiproto tree _with_ both patches you > mentioned early on this thread. > > BTW, I can see all those channels just fine using a DM800 and the > provider original decoder with my subscription card. > > I'm positive that dish/lnb/connections aren't the problem. > > Thanks for taking the time to address this particular issue. > > Chris > As promised, a log with the exact same conditions described above, but with increase_timeout.patch and fix_iterations.patch applied, referred to on this same thread. Chris
diff -r a4731ed28cac linux/drivers/media/dvb/frontends/stb0899_drv.c --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Tue Jan 27 23:29:44 2009 +0400 +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Jan 28 01:08:25 2009 +0400 @@ -1461,19 +1461,16 @@ struct stb0899_config *config = state->config; s32 iter_scale; - u32 reg; iter_scale = 17 * (internal->master_clk / 1000); iter_scale += 410000; - iter_scale /= (internal->srate / 1000000); - iter_scale /= 1000; + iter_scale /= (internal->srate / 1000); if (iter_scale > config->ldpc_max_iter) iter_scale = config->ldpc_max_iter; - reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); - STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); - stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); + stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, iter_scale); + stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_ITER_SCALE, STB0899_OFF0_ITER_SCALE, iter_scale); } static enum dvbfe_search stb0899_search(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)