Bug #5744

linuxdvb: frontend lock broken?

Added by Luis Alves almost 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
git master
Affected Versions:


I have "multi standard" adapters where I'm using DVB-C and DVB-S inputs.

They work perfectly when tuning a single service but when a second service starts tvheadend is ignoring the fact that the adapter might be already in use by another "standard".


adapter 0 (dvb-c + dvb-s)
adapter 1 (dvb-c + dvb-s)

1) Tune to a DVB-S service, stream starts on adapter 0
2) Tune to a DVB-C service, tvheadend will try to start the service on adapter 0 (and actually receiving the data from dvb-s)

Shouldn't adapter 0 be "locked" and unavailable for the DVB-C network?


tbs6522.png (89.4 KB) tbs6522.png Joe User, 2019-10-10 09:15



Updated by Joe User almost 3 years ago

I have seen this also with my TBS 6522 card. But worse than the second service not working, it keeps resetting the tuning of the first service each time it tries to re-tune.

I guess tvheadend cannot easily detect a card which presents multiple frontends as separate tuners, but a manual option to limit the adapter to use only one frontend at a time would be nice if the driver doesn't lock the tuner.

I never tested trying to use a dvb-c and dvb-t at the same time, but I imagine it would be the same situation.

It hasn't really been a problem for me as I almost never record from dvb-c (I use stb for that). But if I did, I would probably split the cable and feed it to both adapters. Then with a new setting, hopefully if adapter 0 dvb-s is in use, a new recording for dvb-c would automatically use adapter 1 (assuming it was not busy...)


Updated by saen acro almost 3 years ago

To be clear you try to switch frontend type on-demand?


Updated by Joe User almost 3 years ago

The TBS 6522 has four physical inputs, but only two tuners and the drivers present it as two adapters with 5 frontends each:

But only one frontend from each adapter can be used at a time (for a max total of 2 at a time.)


Updated by Joe User almost 3 years ago

On a closer look, I noticed for both adapters, all dvb-c/t are shown as frontend0



and the dvb-s are shown as frontend1 for each adapter



So, trying to use a dvb-c and dvb-t should recognize that the frontend is in use already, but when using frontend1, tvheadend assumes frontend0 is free when in fact it is not. I would have thought that the drivers would take care of this, but apparently they do not.


Updated by Luis Alves almost 3 years ago

Exactly as Joe User described.
Both frontend0 and frontend1 use the same demux0 path.

Any hint where this 'lock' could be done?
I'm trying to implement it and all help is wellcome.


Updated by saen acro almost 3 years ago

TBS6522 Multi-standard Dual Tuner PCI-e Card
on tuner 1 can work only one frontend
same on tuner 2
if multiple frontends enabled on same tuner will not work


Updated by saen acro almost 3 years ago


there is some strange software TBS6522 ChangeMode Tool with change frontend routing.


Updated by saen acro almost 3 years ago


Satellite Cable to LNB / 0
cd /dev/dvb/adapter0
# ln -s demux0 demux1
# ln -s dvr0 dvr1
# ln -s net0 net1

Satellite Cable to LNB / 1
cd /dev/dvb/adapter1
# ln -s demux0 demux1
# ln -s dvr0 dvr1
# ln -s net0 net1

Updated by Joe User almost 3 years ago

Sean Sean - I think those links are only for programs which assume frontend1 always uses demux1 and dvr1 etc... tvheadend 4.3 properly detects the frontend and demux, but maybe 4.2 did not???

Here is a quick hack you can try until you or Jaroslav makes a real fix: :)

diff --git a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
index 4afb2d2a7..3be052c70 100644
--- a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
+++ b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
@@ -613,6 +613,15 @@ linuxdvb_frontend_is_enabled
     return MI_IS_ENABLED_OK;
   if (lfe->lfe_in_setup)
     return MI_IS_ENABLED_RETRY;
+  LIST_FOREACH(lfe2, &lfe->lfe_adapter->la_frontends, lfe_link) {
+    if (!strcmp(lfe2->lfe_fe_path, lfe->lfe_fe_path) && strcmp(lfe2->lfe_dmx_path, lfe->lfe_dmx_path))
+      continue;
+//  if (LIST_FIRST(&lfe2->mi_mux_active))
+    if (lfe2->lfe_locked || lfe2->lfe_in_setup)
+      return MI_IS_ENABLED_RETRY;
+  }
   if (lfe->lfe_type != DVB_TYPE_S)
     goto ok;

(the commented out line would be an alternative test - I don't know which is better?)
I am not sure how this would affect other (normal) adapters... Maybe an option needs to be added whether or not to make the test?


Updated by Jaroslav Kysela almost 3 years ago

Could you test v4.3-1812-g3004a0f3e ?


Updated by Michael Marley almost 3 years ago

This commit seems to cause an FTBFS:

src/input/mpegts/linuxdvb/linuxdvb_frontend.c: In function ‘lfe_group’:
src/input/mpegts/linuxdvb/linuxdvb_frontend.c:55:36: error: ‘lfe’ undeclared (first use in this function); did you mean ‘lfe2’?
          strcmp(lfe2->lfe_fe_path, lfe->lfe_fe_path) == 0;
src/input/mpegts/linuxdvb/linuxdvb_frontend.c:55:36: note: each undeclared identifier is reported only once for each function it appears in
src/input/mpegts/linuxdvb/linuxdvb_frontend.c:56:1: error: control reaches end of non-void function [-Werror=return-type]

Updated by Jaroslav Kysela almost 3 years ago



Updated by Luis Alves almost 3 years ago

Jaroslav Kysela wrote:


Seems fixed.

Thanks JK!


Updated by Luis Alves almost 3 years ago

By the way Joe User, you patch also worked after fixing the logic:
(it should be an or instead of an and)

if (!strcmp(lfe2->lfe_fe_path, lfe->lfe_fe_path) || strcmp(lfe2->lfe_dmx_path, lfe->lfe_dmx_path))

Anyway, this can be closed now...

Once again, thanks!


Updated by Joe User almost 3 years ago

My quick hack works fine because we are looking for the specific case of same adapter AND different frontends AND same demux. Using an OR would work in your specific case, but would block on any adapter which has more than one frontend regardless of demux since the second part would not even be evaluated after the first part being TRUE (1).


Updated by Jaroslav Kysela almost 3 years ago

  • Status changed from New to Fixed

Also available in: Atom PDF