Tvheadend

Ville Aakko wrote:

Hi,

I have an Octopus DDBridge with dual DVB C/T (might be T2 but I don't remember for sure) tuners. I only watch and record DVB-C broadcasts.

Usually (without any module loading parameters) there will be two subdirectories created:


$ ls /dev/dvb/*

/dev/dvb/adapter0:
demux0 dvr0 frontend0 net0

/dev/dvb/adapter1:
demux0 dvr0 frontend0 net0

The ddbridge module has preliminary support for a hardware CAM (which I don't care for now actually since the service / channels available here are c*ap, overprized and require a CI+ for anything worth watching, if it wasn't overprized). However, the recommended way to use these devices with the hardware CAM is to use the adapter_alloc=3 module parameter, which will result in all frontends residing in the same adapter subdirectory (along with redirecting the stream trough the CAM):

$ ls /dev/dvb/*
demux0 demux1 dvr0 dvr1 frontend0 frontend1 net0 net1


(obviosly I have not connected the CAM to the octopus at the moment).

However, it seems that with all frontends in one directory, tvheadend does not seem to like this setup:

maalis 05 00:29:00 ArkkiVille tvheadend[28551]: linuxdvb: adapter 0 has multiple tuners 2 for type DVB-T, only one can be used at a time
maalis 05 00:29:00 ArkkiVille tvheadend[28551]: linuxdvb: adapter 0 has multiple tuners 2 for type DVB-C, only one can be used at a time

In any case, recording channels from two different muxes fails.

However, without the adapter_alloc parameter (or with the right given for it value), with frontend device nodes in their own adapter directories, recording channels from different muxes succeeds.

But with Linuxdvb tools, tuning is possible even in the case of multiple frontends in the same adapter dir, simultaneously. Probably zapping etc. also, but haven't acttually tried it.

From 'modinfo ddbridge':

parm: adapter_alloc:0-one adapter per io, 1-one per tab with io, 2-one per tab, 3-one for all (int)

AFAICT, tvheadend just silently gives up. According to status view and logs, it doesn't even try to use the tuners in the configuration case.

The question is: Is tvheadends behaviour intentional, or just unnecessarily restrictive? Or, perhaps the ddbridge module is doing something that is not according to the linux-dvb spec?

I believe that in an earlier tvheadend version, using both tuners simultaneously was possible with adapter_alloc=3, but I may be mistaken.

I'm using tvheadend-4.0.8-1 (from Arch Linuxs AUR) - there is a git PKGBUILD available, too, if you think I should try current GIT.

Cheers!

Most cards/devices only allow one frontend per tuner to be used at a time looks like your card is an exception to the "rule".

Mark Clarkstone wrote:

Most cards/devices only allow one frontend per tuner to be used at a time looks like your card is an exception to the "rule".

First: This is a real dual tuner card (as in not a single hybrid DVB-C/T tuner). Two tuners, both of them can receive one of DVB-C or DVB-T(2). So this is not the case.

What causes confusion here, is that frontend is not the same as a single delivery system (supported by the tuner in question). I know that there are adapters (or drivers) that implement hybrid DVB-T/C/S tuners this way: there are several frontends in the adapterX subdirectory for each delivery standard, and from these only one can be used at any one time.

But I think this is actually wrong (but I'm only guessing here - it could also be that the linux-dvb spec has changed at some point - during v3->v5 change, perhaps? In that case the implementation some drivers follow, is correct, but outdated). I actually think this way is a more common implementation (frontend node per delivery system) - v.s. single frontend for each tuner, delivery sysytem chooseable.

The DVB api makes it possible to change the frontend delivery system being used. For example on my card:


$ dvb-fe-tool
Device DRXK DVB-C DVB-T (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_1_2
CAN_FEC_2_3
CAN_FEC_3_4
CAN_FEC_5_6
CAN_FEC_7_8
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_MUTE_TS
CAN_QAM_16
CAN_QAM_32
CAN_QAM_64
CAN_QAM_128
CAN_QAM_256
CAN_RECOVER
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.10, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems:
[DVBC/ANNEX_A]
DVBC/ANNEX_C
DVBT


And fro m dvb-fe-tool --help:
-d, --set-delsys=PARAMS set delivery system

With -d, I gan change each of the tuners independently to try to receive DVB-T (whether they reside in their own directories or not does not matter, this needs to be done in any case; also, there is never separate frontend nodes for DVB-C and DVB-T on my tuners driver). I just don't have any aerial antenna to succesfully do any actual recception

But my knowledge of the DVB API is not that great, and I don't even know where the documentation is - so my conclusions is only from my findings I've told above. I'm not sure what the API documentation says on this.

What is unclear, is this (and this was my question on the OP, too): Is it correct to assume that frontends that are in the same adapter directory, should not be assumed to be actually the same tuner and not be useable simultaneously? In the ddbridge modules case this is not the case (with adapter_alloc=3 parameter), and because tvheadend assumes contrary, it will fail. But, is the ddbridge module doing something non-standard in this case? I do find it a bit confusing them being in the same directory, I must admit.

Ville Aakko wrote:

Mark Clarkstone wrote:

Most cards/devices only allow one frontend per tuner to be used at a time looks like your card is an exception to the "rule".

First: This is a real dual tuner card (as in not a single hybrid DVB-C/T tuner). Two tuners, both of them can receive one of DVB-C or DVB-T(2). So this is not the case.

What causes confusion here, is that frontend is not the same as a single delivery system (supported by the tuner in question). I know that there are adapters (or drivers) that implement hybrid DVB-T/C/S tuners this way: there are several frontends in the adapterX subdirectory for each delivery standard, and from these only one can be used at any one time.

But I think this is actually wrong (but I'm only guessing here - it could also be that the linux-dvb spec has changed at some point - during v3->v5 change, perhaps? In that case the implementation some drivers follow, is correct, but outdated). I actually think this way is a more common implementation (frontend node per delivery system) - v.s. single frontend for each tuner, delivery sysytem chooseable.

The DVB api makes it possible to change the frontend delivery system being used. For example on my card:


$ dvb-fe-tool
Device DRXK DVB-C DVB-T (/dev/dvb/adapter0/frontend0) capabilities:
CAN_FEC_1_2
CAN_FEC_2_3
CAN_FEC_3_4
CAN_FEC_5_6
CAN_FEC_7_8
CAN_FEC_AUTO
CAN_GUARD_INTERVAL_AUTO
CAN_HIERARCHY_AUTO
CAN_INVERSION_AUTO
CAN_MUTE_TS
CAN_QAM_16
CAN_QAM_32
CAN_QAM_64
CAN_QAM_128
CAN_QAM_256
CAN_RECOVER
CAN_TRANSMISSION_MODE_AUTO
DVB API Version 5.10, Current v5 delivery system: DVBC/ANNEX_A
Supported delivery systems:
[DVBC/ANNEX_A]
DVBC/ANNEX_C
DVBT


And fro m dvb-fe-tool --help:
-d, --set-delsys=PARAMS set delivery system

With -d, I gan change each of the tuners independently to try to receive DVB-T (whether they reside in their own directories or not does not matter, this needs to be done in any case; also, there is never separate frontend nodes for DVB-C and DVB-T on my tuners driver). I just don't have any aerial antenna to succesfully do any actual recception

But my knowledge of the DVB API is not that great, and I don't even know where the documentation is - so my conclusions is only from my findings I've told above. I'm not sure what the API documentation says on this.

What is unclear, is this (and this was my question on the OP, too): Is it correct to assume that frontends that are in the same adapter directory, should not be assumed to be actually the same tuner and not be useable simultaneously?

In the ddbridge modules case this is not the case (with adapter_alloc=3 parameter), and because tvheadend assumes contrary, it will fail. But, is the ddbridge module doing something non-standard in this case? I do find it a bit confusing them being in the same directory, I must admit.

I've never seen any other cards do this (and I'm not saying it's incorrect because I honestly don't know). I suspect Tvheadend just assumes that the tuner isn't able to use both frontends of the same type concurrently as is the case for many cards/devices.

If you really want definitive answers I'd ask the linuxtv mailing list and if you want Tvheadend to change its behavior in such cases I'd open a bug/feature issue on here.

I'll ping the main dev on IRC to take a look at this thread too.