Bug #5330
Using multiple DVB frontends simultaneously on Si21662
100%
Description
I am using Si21662 DVB adapter, which has two DVB-S frontends:
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
History
Updated by Luis Alves about 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".
Updated by Peter Bašista about 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.
Updated by saen acro about 6 years ago
https://github.com/Openeight/enigma2/tree/master/lib
if this can help
Updated by Joe User about 6 years ago
- File TV_adapters.png TV_adapters.png added
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).
Updated by Pablo R. about 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.
Updated by Jaroslav Kysela about 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.
Updated by Jaroslav Kysela about 6 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|f01679febc6fdccf452d43043b5bc212c4db6fcf.
Updated by Luis Alves about 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(?).
Updated by Luis Alves about 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!
Updated by Jaroslav Kysela about 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.
Updated by Peter Bašista about 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.
Updated by Peter Bašista about 6 years ago
- File frontend1.log frontend1.log added
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.
Updated by Jaroslav Kysela about 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 :-)
Updated by Peter Bašista about 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
.
Updated by Jaroslav Kysela about 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?
Updated by Peter Bašista about 6 years ago
- File lslR.dev.dvb.txt lslR.dev.dvb.txt added
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
Updated by Peter Bašista about 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.
Updated by Jaroslav Kysela about 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.
Updated by Luis Alves about 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?
Updated by Joe User about 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.
Updated by Luis Alves about 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?
Updated by Peter Bašista about 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.
Updated by Jaroslav Kysela about 6 years ago
It seems that enigma2 drivers require also this settings: https://github.com/catalinii/minisatip/blob/master/src/dvb.c#L397-L419
Updated by Luis Alves about 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")
Updated by Luis Alves about 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);
Updated by Luis Alves about 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> [...] }
Updated by Peter Bašista about 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.
Updated by Luis Alves about 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));
Updated by Luis Alves about 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));
Updated by Peter Bašista about 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.
Updated by Luis Alves about 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).
Updated by Ricardo Rocha about 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
Updated by Luis Alves about 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.
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.
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.
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.
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.
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
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