Project

General

Profile

Bug #5330

Using multiple DVB frontends simultaneously on Si21662

Added by Peter Bašista almost 6 years ago. Updated almost 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
DVB
Target version:
-
Start date:
2018-11-17
Due date:
% Done:

100%

Estimated time:
Found in version:
4.3-1532~g409a70630
Affected Versions:

Description

I am using Si21662 DVB adapter, which has two DVB-S frontends:

Si21662 DVB adapter as shown in Tvheadend

For some reason, Tvheadend cannot use both of them simultaneously. But it can use each one individually.

When I stream one channel from frontend0 and then try to stream some other channel from frontend1, Tvheadend would not even attempt to use frontend1 and start tuning. Instead, it immediately fails with error message "No input source available" and then "No free adapter".

I am not sure why it happens, but the device I am trying it on is marketed as "dual tuner", so I believe it should be perfectly possible to use both frontends simultaneously.


Files

dvb.adapter.png (63.7 KB) dvb.adapter.png Si21662 DVB adapter as shown in Tvheadend Peter Bašista, 2018-11-17 17:55
TV_adapters.png (62.5 KB) TV_adapters.png Joe User, 2018-11-18 21:57
frontend1.log (2.65 KB) frontend1.log Log from frontend1 trying to tune while frontend0 is not in use Peter Bašista, 2018-11-19 17:04
lslR.dev.dvb.txt (1.84 KB) lslR.dev.dvb.txt output from ls -lR /dev/dvb Peter Bašista, 2018-11-19 23:38

History

#1

Updated by Luis Alves almost 6 years ago

Usually that is normal.
One adapter can only stream from one frontend at once.

It does have 2 tuners (one for sat, another for terrestrial/cable) but to simultaneously stream from both, you need 2 "adapters".

#2

Updated by Luis Alves almost 6 years ago

By the way, what's the product name/model?

#3

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

By the way, what's the product name/model?

It is the Octagon SF4008:
https://www.octagon-germany.eu/downloads/digital-receiver/hdtv-receiver/SF4008UHDdw/
https://www.ebay.com/itm/Octagon-SF4008-Triple-4K-2x-DVB-S2X-E2-Linux-UHD-HDTV-SAT-Receiver-OpenATV-IPTV/172078851032

It has two slots for tuner cards. I am using it in a configuration where the first card is a dual DVB-S tuner and the second card is a combined DVB-C and DVB-T tuner. The device itself is restricted to at most 3 tuners for some reason, so even if you use two dual tuner cards, you would only be able to use 3 tuners.

This restriction manifests itself in a fact that there are only 3 frontends available (all on the same adapter). The first two DVB-S tuners each have its own frontend (as I have mentioned, frontend0 and frontend1) while the DVB-C and DVB-T tuners share the third frontend (frontend2).

Luis Alves wrote:

One adapter can only stream from one frontend at once.

Do you have evidence supporting such a statement? An existing Linux DVB stack restriction or something similar?

I have no reason to not believe the manufacturer's claim that the device can utilize the dual tuner DVB-S card in a way that both tuners are operated simultaneously. I believe that the fact that the tuners manifest themselves as a single adapter with multiple frontends is a mere technicality.

#5

Updated by Joe User almost 6 years ago

My TBS-6522 has two tuners but four inputs. It shows up in tvheadend as two adapters each with two frontends (a DVB-T/T2/C as frontend 0, and a DVBS/S2 as frontend 1).
I can use any frontend of adapter0 and any frontend of adapter1 at the same time with no problems.
I cannot use two frontends from the same adapter at the same time. But, different from you, it seems to at least try to tune the second and keeps outputting a "[warning] subscription: restarting channel ..." , but never works. If I stop the first subscription while the second is still retrying, the second will start to work.
I assume is is by design of the card.
I am using the tbsdtv open source drivers (forked from Luis).

#6

Updated by Pablo R. almost 6 years ago

Why not triying to use w_scan or similar to test both frontends at the same time? To find if it is a hw or tvheadend issue.

#7

Updated by Jaroslav Kysela almost 6 years ago

It's tvh problem. Actually, when more different frontend types are detected, the exclusive behaviour is selected (only one tuner can be used for all of the frontends). TVH should do this only if the frontend device name matches.

#8

Updated by Jaroslav Kysela almost 6 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|f01679febc6fdccf452d43043b5bc212c4db6fcf.

#9

Updated by Luis Alves almost 6 years ago

Peter Bašista wrote:

Luis Alves wrote:

One adapter can only stream from one frontend at once.

Do you have evidence supporting such a statement? An existing Linux DVB stack restriction or something similar?

Like I said before "usually that is normal" - in your case I believe it's not true.

The usual way to code dvb drivers is to create 1 adapter per "TS data path", aggregating all the frontends that share that data path in 1 adapter (that are mutually exclusive).
But this box drivers seem to add all the demodulators to 1 adapter.

The 3 tuner limit on the box is probably due to the SoC that has only 3 physical TS data path inputs.
With your tuner combo, you should be able to stream from 3 different frontends at once: 2x dvb-s + 1xdvbt/c
And I guess that if you swap tuners, the combo becomes: 1x dvb-s + 2xdvbt/c

Jaroslav Kysela wrote:

It's tvh problem. Actually, when more different frontend types are detected, the exclusive behaviour is selected (only one tuner can be used for all of the frontends). TVH should do this only if the frontend device name matches.

Not true, this box can use both DVB-S at once (and device name matches).
The exclusivity should not exist - on a streaming attempt, tvh should try to open the frontend - the driver should return busy/refuse if another one is locking the adapter, or make it a config option, per adapter(?).

#10

Updated by Luis Alves almost 6 years ago

Jaroslav Kysela wrote:

TVH should do this only if the frontend device name matches.

Oh, when you say "device name" matches you mean the device path: if (/dev/dvb/adapterX/frontendY == /dev/dvb/adapterX/frontendY)

Agree!

#11

Updated by Jaroslav Kysela almost 6 years ago

Luis Alves wrote:

Jaroslav Kysela wrote:

TVH should do this only if the frontend device name matches.

Oh, when you say "device name" matches you mean the device path: if (/dev/dvb/adapterX/frontendY == /dev/dvb/adapterX/frontendY)

Yes, I meant system's device name not the DVBAPI's device name.

#12

Updated by Peter Bašista almost 6 years ago

Jaroslav Kysela wrote:

Applied in changeset commit:tvheadend|f01679febc6fdccf452d43043b5bc212c4db6fcf.

Thank you! This change indeed seems to help. I am now able to use both frontends simultaneously.

#13

Updated by Peter Bašista almost 6 years ago

There is, however, still another issue. Tvheadend cannot start streaming from frontend1 when frontend0 is not already in use. It would try, but eventually fail with "no data" message (a log is attached). The problem is not symmetrical, i.e. frontend0 can be used without using frontend1 at the same time.

If frontend0 is already streaming, then frontend1 is able to start streaming from the same transponder as well. In such case, stopping frontend0 afterwards has no effect and frontend1 would still keep streaming. But when frontend0 is not in use or when it uses a different transponder, then frontend1 would not be able to start because of "no data" issue mentioned above.

When scanning using frontend1 while frontend0 is not in use, the SNR and Signal Strength values in the Status->Stream tab of Tvheadend web interface keep showing slightly different values for different transponders. But the scanning itself fails.

Because of that, I think that Tvheadend is actually able to tune to the specified frequency and obtain some basic information like signal strength, etc. from frontend1. But it can only get the actual stream data from frontend1 if frontend0 is used at the same time with the same transponder settings.

#14

Updated by Jaroslav Kysela almost 6 years ago

There is 'Linked input' field, so you can 'tight' inputs together. In this case, TVH uses both inputs together (the second input is tuned to a random different mux if no subscription is requested).

By the way: It's not a first broken driver which behaves like this :-)

#15

Updated by Peter Bašista almost 6 years ago

Also, when frontend0 is streaming from a specific transponder and I try to scan using frontend1 at the same time, the scanning succeeds, but the discovered channels are the same for all transponders. The SNR and Signal Strength values are slightly different for each scanned transponder, so I assume that the actual tuning works fine on frontend1.

Maybe it points to an issue where Tvheadend always tries to get the stream data from frontend0, even if asked for stream data from frontend1.

#16

Updated by Jaroslav Kysela almost 6 years ago

You should see "Input path" and "Demux path" in the read-only fields in the adapter settings. Could you check, if they are different?

#17

Updated by Peter Bašista almost 6 years ago

Jaroslav Kysela wrote:

You should see "Input path" and "Demux path" in the read-only fields in the adapter settings. Could you check, if they are different?

Yes, sure. They are different:

frontend0:

Frontend path:        /dev/dvb/adapter0/frontend0
Input path:           /dev/dvb/adapter0/dvr0
Demux path:           /dev/dvb/adapter0/demux0
Frontend number:      0
Device path in sysfs: devices/platform/sf4008.0/dvb/dvb0.frontend0

frontend1:

Frontend path:        /dev/dvb/adapter0/frontend1
Input path:           /dev/dvb/adapter0/dvr1
Demux path:           /dev/dvb/adapter0/demux1
Frontend number:      1
Device path in sysfs: devices/platform/sf4008.0/dvb/dvb0.frontend1
#18

Updated by Peter Bašista almost 6 years ago

Jaroslav Kysela wrote:

There is 'Linked input' field, so you can 'tight' inputs together. In this case, TVH uses both inputs together (the second input is tuned to a random different mux if no subscription is requested).

Yes, I am aware of that feature. But it does not help in my case.

The problem is not with one of the frontends behaving incorrectly only while the other one is not running. Instead, frontend1 always behaves incorrectly, even when frontend0 is running at the same time. From what I have observed, it seems like frontend1 is only able to get the data from the same transponder to which frontend0 is currently tuned.

On the other hand, it seems like Tvheadend can control the tuning of both frontends individually just fine, because dvb-fe-tool confirms that the frequencies and other parameters indeed do change as requested by Tvheadend.

To be clear, this did not start happening with the above mentioned patch that has fixed the usage of multiple frontends at the same time. As far as I can remember, it has always behaved like that.

#19

Updated by Jaroslav Kysela almost 6 years ago

The drivers for enigma2 might have some special features. It seems that the data routing for the second frontend requires more settings. You need to analyze the enigma2 / distro sources to look, how the second frontend is used.

#20

Updated by Luis Alves almost 6 years ago

Jaroslav Kysela wrote:

You need to analyze the enigma2 / distro sources to look, how the second frontend is used.

I think the box drivers are closed source.

Peter Bašista wrote:

To be clear, this did not start happening with the above mentioned patch that has fixed the usage of multiple frontends at the same time. As far as I can remember, it has always behaved like that.

From your description of the box behavior looks like the data path of frontend1 is wrongly set to frontend0.
This looks like broken drivers... has anyone reported this problem to octagon?

What about the dvb-c/t frontend?
Can you stream from that one at the same time as streaming from the dvb-s/s2?

#21

Updated by Joe User almost 6 years ago

Luis Alves wrote:

Jaroslav Kysela wrote:

You need to analyze the enigma2 / distro sources to look, how the second frontend is used.

I think the box drivers are closed source.

Yes, but I think he was more referring to how enigma2 used the drivers. A quick look shows there does seem to be some special handling. [[https://github.com/Openeight/enigma2/search?q=HAVE_HISILICON&unscoped_q=HAVE_HISILICON]]

Peter Bašista wrote:

To be clear, this did not start happening with the above mentioned patch that has fixed the usage of multiple frontends at the same time. As far as I can remember, it has always behaved like that.

From your description of the box behavior looks like the data path of frontend1 is wrongly set to frontend0.
This looks like broken drivers... has anyone reported this problem to octagon?

Depends on your definition of "broken" because apparently they work ok for enigma2. Of course there is always the possibility of two wrongs making a right. ;)

#22

Updated by Luis Alves almost 6 years ago

apparently they work ok for enigma2

You mean that within e2 you can stream from 2 different dvbs muxes?

I don't think e2 has any special frontend handling code - just plain standard ioctl calls.
And yes, that code is public: https://github.com/openatv/enigma2/blob/6.2/lib/dvb/frontend.cpp#L2581

What about this question:

What about the dvb-c/t frontend?
Can you stream from that one at the same time as streaming from the dvb-s/s2?

Can you try?

#23

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

You mean that within e2 you can stream from 2 different dvbs muxes?

Yes, I believe it is possible, although I have not personally tried it. But some people report it works with Enigma2.

For instance, here is an external forum thread about some multistream issues which tangentially resemble this issue. It was eventually worked-around by disabling some kind of tuner conflict detection in Enigma2 (in Python code part).

Anyway, the author Arcy mentions that:

... with plain DVB-S/S2 channels -- I can record those freely from up to three different satellites simultaneously

which seems to confirm that simultaneous and independent usage of frontend0 and frontend1 should be possible.

Luis Alves wrote:

What about the dvb-c/t frontend?
Can you stream from that one at the same time as streaming from the dvb-s/s2?

I did not try it, so I am not sure. I do not have physical access to the device and its DVB-C/T input is currently disconnected, so I cannot do real experiments with it. At least not in the near future, I am sorry.

#24

Updated by Jaroslav Kysela almost 6 years ago

It seems that enigma2 drivers require also this settings: https://github.com/catalinii/minisatip/blob/master/src/dvb.c#L397-L419

#25

Updated by Luis Alves almost 6 years ago

Jaroslav Kysela wrote:

It seems that enigma2 drivers require also this settings: https://github.com/catalinii/minisatip/blob/master/src/dvb.c#L397-L419

Nice finding.
Should be easy to try and see if it solve the issue.

Peter,
You could try with a quick hack by placing something like this on tvh frontend open code - not really sure where but Jaroslav can help here:
(where i is the frontend number and assuming they are related)

sprintf(buf, "/dev/dvb/adapter0/frontend%d", i);
int dmx = open(buf, O_RDWR | O_NONBLOCK);
if (dmx > 0) {
    ioctl(dmx, _IOW('o', 49, int), i);
    close(dmx);
}

Jaroslav,
If this really solves the issue, maybe a new config entry on the frontend tab "Set demux source" can be added for enigma boxes (default empty - don't do anything).
(or add it on the code conditionally with a configure option like "--enable-enigma2")

#26

Updated by Luis Alves almost 6 years ago

Typo above!
Should be (and also adding the adapter_nr as variable):

sprintf(buf, "/dev/dvb/adapter%d/demux%d", adapter_nr, frontend_nr);
#27

Updated by Luis Alves almost 6 years ago

A quick look at the box frontend driver dasm'ed code seems that the init function always sets the value to '1':

xpt_dmx_set_source(r0, r1)
{
}

odin_xpt_init(...)
{
[...]
   12278:    e1a00004     mov    r0, r4
   1227c:    e3a01001     mov    r1, #1   
   12288:    eafff27f     b    ec8c <xpt_dmx_set_source>
[...]
}
#28

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

A quick look at the box frontend driver dasm'ed code seems that the init function always sets the value to '1':

Wow, an interesting find!

I can, of course, try to add the snippet you have mentioned and compile. I am just not familiar with Tvheadend source code, so I am also not sure where to put it.

#29

Updated by Luis Alves almost 6 years ago

Try something as simple as:

diff --git a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
index 82021020f..9b8d8edcf 100644
--- a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
+++ b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
@@ -1268,6 +1268,8 @@ linuxdvb_frontend_open_pid0
     return;
   }

+  ioctl(fd, _IOW('o', 49, int), lfe->lfe_number);
+
   /* Install filter */
   tvhtrace(LS_LINUXDVB, "%s - open PID %04X (%d) fd %d", name, pid, pid, fd);
   memset(&dmx_param, 0, sizeof(dmx_param));
#30

Updated by Luis Alves almost 6 years ago

Typo above (the ioctl takes a pointer as arg)! It should be:

diff --git a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
index 82021020f..9b8d8edcf 100644
--- a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
+++ b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
@@ -1268,6 +1268,8 @@ linuxdvb_frontend_open_pid0
     return;
   }

+  ioctl(fd, _IOW('o', 49, int), &lfe->lfe_number);
+
   /* Install filter */
   tvhtrace(LS_LINUXDVB, "%s - open PID %04X (%d) fd %d", name, pid, pid, fd);
   memset(&dmx_param, 0, sizeof(dmx_param));
#31

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

Typo above (the ioctl takes a pointer as arg)! It should be:

Thank you! I have tried this patch and it indeed helps.

I am now able to use both frontends simultaneously. I have tried to stream from one transponder on frontend0 and at the same time stream from a different transponder on frontend1 and it worked well. Scanning also works correctly on both frontends.

So, again, thank you for this, it seems like you have identified the root cause of the problem.

#32

Updated by Luis Alves almost 6 years ago

All credit goes to Jaroslav :) as he's the one who found the IOCTL call on minisatip.

Maybe he can include this somehow on tvh (maybe within a #ifdef specific for enigma boxes enabled by a configure switch).

#33

Updated by Ricardo Rocha almost 6 years ago

small apart question... since the tvheadend can run on enigma stb... do you think the FBC tunners will also work? i am asking this cause i think minisatip also have some changes to permit FBC tuners to work well!

Thanks

#34

Updated by Luis Alves almost 6 years ago

Ricardo Rocha wrote:

small apart question... since the tvheadend can run on enigma stb... do you think the FBC tunners will also work? i am asking this cause i think minisatip also have some changes to permit FBC tuners to work well!

Thanks

It should work with minimal changes. All that's needed is to link the tuners to a frontend (write 0 or 1 to /proc/stb/frontend/%d/fbc_connect).
Or just have a script to do it at startup pre-assigning the tuners to each frontend (echo [0|1] > /proc/stb/frontend/%d/fbc_connect).

This is similar to my setup, a TBS6909 (4 tuners with 8 frontends). In my case I do the "linking" on the driver side and 4 tuners is enough to have 1 per band/pol.

#35

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

All credit goes to Jaroslav :) as he's the one who found the IOCTL call on minisatip.

Definitely. Thanks Jaroslav!

Maybe he can include this somehow on tvh (maybe within a #ifdef specific for enigma boxes enabled by a configure switch).

That would be nice. Although I believe the behavior should be selected on runtime and perhaps should be user-overridable. Shall I create a separate bug about it?

BTW, a Bitbake recipe for Tvheadend has recently been brought back to openembedded's meta-multimedia layer:
http://cgit.openembedded.org/meta-openembedded/tree/meta-multimedia/recipes-dvb/tvheadend/tvheadend_git.bb
so it should be even simpler for anyone to build Tvheadend for their favourite receiver.

#36

Updated by Pablo R. almost 6 years ago

Peter Bašista wrote:

Shall I create a separate bug about it?

I think so, since this bug report is already closed.

#37

Updated by Peter Bašista almost 6 years ago

Pablo R. wrote:

I think so, since this bug report is already closed.

Ok. A feature #5379 has been created.

#38

Updated by Peter Bašista almost 6 years ago

Luis Alves wrote:

What about the dvb-c/t frontend?
Can you stream from that one at the same time as streaming from the dvb-s/s2?

I was finally able try it. I have used a recent Tvheadend version that contains patches used to fix this issue, as well as the issue #5379. I can confirm that Tvheadend can use all three frontends (two DVB-S and one DVB-T) simultaneously.

#39

Updated by Sam M. almost 6 years ago

There are still conflicts when idle scan enabled on dvbs frontends and tuning on dvbt channels

2019-01-19 19:14:49.745 mpegts: 586.166MHz in DVBT Network - scan no data, failed
2019-01-19 19:14:51.745 subscription: 002B: service instance is bad, reason: No input detected
#40

Updated by Sam M. almost 6 years ago

This is more precisely only at the same time when the dvbs #2 (frontend1) is active on a channel/mux, that the signal of dvbt is disturbed.
Checked the F-connector and interchanged the 2 lnb sat input of the receiver card but nothing change. Don't understand why it is different than the frontend0

#41

Updated by Sam M. almost 6 years ago

New issue opened #5513

Also available in: Atom PDF