Tvheadend

The problem is the mix of new dvbapi linux kernel headers and the driver which accepts only old PLS code and rejects the new settings. Could you upgrade your drivers? We can probably add another switch to the tuner configuration to avoid using the new DTV_SCRAMBLING_SEQUENCE_INDEX for those old drivers.

To explain this more:

The code for DTV_STREAM_ID which adds PLS code is the old unofficial way.
The new (and only official) dvbapi is to use DTV_SCRAMBLING_SEQUENCE_INDEX for PLS.

Jaroslav,

Thanks for the explanation. It helps.

It is however a bit worse than you write: the drivers do not simply ignore the DTV_SCRAMBLING_SEQUENCE_INDEX
command (because then it would all work) but they interpret it, leading to "no picture".
The wrong result could mean the drivers do the wrong thing or tvheadend sends the wrong information.

I already use very recent drivers
https://github.com/tbsdtv/linux_media
639c3511e33945952ac6469c07f66af83a81d124
4/11/2018 (latest version)
These drivers donwload and patch linux_media, which is dated 25/1/2019 (there have few updates
since then, and none seem relevant)

So an upgrade is not going to change anything.

When I find some time I can have a look at what goes on in the drivers.

The relevant driver code is:
./v4l/stid135-fe.c

At line 306, it shows the following

    if (p->stream_id == NO_STREAM_ID_FILTER) {
        pls_mode = 0;
        pls_code = 1;
    }
    else {
        pls_mode = (p->stream_id>>26) & 0x3;
        pls_code = (p->stream_id>>8) & 0x3FFFF;
        if (pls_mode == 0 && pls_code == 0)
            pls_code = 1;
    }

    if (p->scrambling_sequence_index) {
        pls_mode = 1;
        pls_code = 0;
    }

Clearly this is very different than similar code for stv0910.c
which actually interprets p->scrambling_sequence_index as a bit field
structure. In the stid135 code, it is a binary flag (which is clearly not
what is intended by dvbapi)

So this explains the problem, but does not provide a solution.
In theory, it should be fairly easy to fix the driver, which should decode
the value created by tvheadend's dvb_sat_pls (in dvb_support.c)
However, the code of dvb_sat_pls is incomprehensible to me.

Furthermore the rest of the stid135 driver code
seems to use the values of pls_mode and
pls_code directly related to what is entered by the user
in tvheadend (and passed via stream_id), rather than the strangely processed
value returned by dvb_sat_pls.

So it does not seem logical that tvheadend first transforms the user input,
and then the drivers would have to undo that transformation, to arrive at the
numbers that the user has input directly.

The scrambling_sequence_index should be handled like the GOLD PLS (standard) code, so the vanilla kernel:

1) drivers/media/dvb-core/dvb_frontend.c

       /* Physical layer scrambling support */
        case DTV_SCRAMBLING_SEQUENCE_INDEX:
                c->scrambling_sequence_index = data;
                break;

2) drivers/media/dvb-frontends/stv0910.c

static void set_pls(struct stv *state, u32 pls_code)
{
        if (pls_code == state->cur_scrambling_code)
                return;

        /* PLROOT2 bit 2 = gold code */
        write_reg(state, RSTV0910_P2_PLROOT0 + state->regoff,
                  pls_code & 0xff);
        write_reg(state, RSTV0910_P2_PLROOT1 + state->regoff,
                  (pls_code >> 8) & 0xff);
        write_reg(state, RSTV0910_P2_PLROOT2 + state->regoff,
                  0x04 | ((pls_code >> 16) & 0x03));
        state->cur_scrambling_code = pls_code;
}

static void set_stream_modes(struct stv *state,
                             struct dtv_frontend_properties *p)
{
        set_isi(state, p->stream_id);
        set_pls(state, p->scrambling_sequence_index);
}

Do you see the difference? Your driver does this:

   if (p->scrambling_sequence_index) {
        pls_mode = 1;
        pls_code = 0;
    }

Which is obviously wrong, if the scrambling_sequence_index is present, the code from this value should be honored not zeroed. Report this to the driver author.

To complete the explanation, the stream_id is masked (0xff) in set_isi() function (drivers/media/dvb-frontends/stv0910.c), so the old (non-accepted / non-standard) behaviour is not handled at all in stv0910.c .

Which is obviously wrong, if the scrambling_sequence_index is present, the code from this value should be honored not zeroed. Report this to the driver author.

Yes, this is what I wrote myself: " In the stid135 code, it is a binary flag (which is clearly not
what is intended by dvbapi)"

In the mean time, I have reported the problem and it has been fixed in the drivers (I have verified that it works).
So this issue can be closed.