Bug #5556
multistream 5.0W not working on tbs6909x - with fix
0%
Description
I have just tested a tbs 6909x tuner card and am trying to get
the multistreams on 5.0W working with the latest tvheadend
(39db47829b65f140f337d4af3110a8906fed6ff8) and the latest
open source tbs drivers.
This does not work and I tracked it down to the following code
in input/mpegts/linuxdvb/linuxdvb_frontend.c around line 1892:
#if 0 //DEEPTHOUGHT
#if DVB_VER_ATLEAST(5,11)
r = dvb_sat_pls(dmc);
if (r != 0) /* default PLS gold code */
S2CMD;
#endif
#endif //DEEPTHOUGHT
When the code is commented out (with the #if 0) all multistreams work on
5.0 (Italian, French).
With the original code, none of the work.
The pls code is already set on earlier source lines, so I wonder what the dvb_sat_pls
call is supposed to do.
My dvbabi versions are:
#define DVB_API_VERSION 5
#define DVB_API_VERSION_MINOR 11
History
Updated by Jaroslav Kysela over 5 years ago
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.
Updated by Jaroslav Kysela over 5 years ago
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.
Updated by Deep Thought over 5 years ago
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.
Updated by Deep Thought over 5 years ago
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.
Updated by Jaroslav Kysela over 5 years ago
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.
Updated by Jaroslav Kysela over 5 years ago
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 .
Updated by Deep Thought over 5 years ago
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.