[linux-dvb] stb0899 troubles
abraham.manu at gmail.com
Sun Feb 25 10:10:08 CET 2007
On 2/25/07, Bernhard Rosenkraenzer <bero at arklinux.org> wrote:
> On Saturday, 24. February 2007 23:56, Bernhard Rosenkraenzer wrote:
> > Actual DVB-S2 channels don't seem to work either -- szap with the patches
> > tunes there and claims to have a lock, but the dvr0 device remains empty.
> I found some oddities in the patched szap code -- fixing them doesn't seem to
> change anything, but maybe they cause odditites elsewhere (or maybe I'm
> misreading things?):
the very same szap was used on dvb-s/dvb-s2 for a couple of people, so
the probability of szap not working is lesser.
> 1. do_tune() sets fe_params.delsys.*.fec = FEC_AUTO;
> but the type of the fec member is dvbfe_fec rather than fe_code_rate_t --
> shouldn't it be set to DVBFE_FEC_AUTO instead, especially because the value
> is not the same?
We use FEC_AUTO, with the API update DVBFE_FEC_AUTO.
> 2. Similarily, there's INVERSION_* vs. DVBFE_INVERSION_* --
> dvb_frontend_parameters takes a fe_spectral_inversion_t which matches
> the use of INVERSION_* in patched szap, but DVBFE_INVERSION_* is
> introduced by the multiproto patch and is set inside the kernel module
> if dvb_force_auto_inversion is on.
Inversion also doesn't matter.
> 3. Nothing in do_tune() sets fe_params.delsys.*.modulation -- but
> 0 is DVBFE_MOD_NONE. Shouldn't it be set to DVBFE_MOD_AUTO
> (or DVBFE_MOD_QPSK/DVBFE_MOD_8PSK depending on dvbs vs. dvbs2)?
> If the modulation parameter is there for DVBFE_GET_PARAMS only, it should
> probably be pointed out in a comment in the header (the way it is done for
> e.g. dvbs2_params.rolloff)
Modulation also doesn't matter.
The only things that do matter
2) symbol rate
3) delivery system
As ralph said, probably wrong pids ?
More information about the linux-dvb