Tvheadend

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".

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

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.

https://github.com/Openeight/enigma2/tree/master/lib
if this can help

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.

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.

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(?).

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!

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.

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.

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 :-)

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.

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

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.

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.

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?

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. ;)

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?

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.

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

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")

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

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

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>
[...]
}

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.

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));

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));

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.

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).

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

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.

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.

Peter Bašista wrote:

Shall I create a separate bug about it?

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

Pablo R. wrote:

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

Ok. A feature #5379 has been created.

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.

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

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

New issue opened #5513