Tvheadend

I am wondering if this is caused, somehow, by the frontend0 symbolrate settings not being reported/seen by TVHeadend - so it doesn't know what are valid or invalid settings, and so ignored them?

Is there anyway of finding out what the reported functionality of a /dev/dvb/ device is from the command line (or is there a debug option somewhere in TV Headend that will?)

Will report back - don't think I saw symbol rates reported, but IF frequencies were. Have discovered that I have v4lutils as an option in my buildroot - so hopefully this will let me know more about the frontend (and let me see if I can scan / zap)?

I do have the driver source code in my kernel build environment - which might be useful. This does talk about min and max symbolrates. Hope I don't have to try hacking the driver - that may well be beyond me! I know that the hardware works within DVBPlayer under Android 4.0 - but the app may possibly only be using a reduced subset of the DVB-API and thus the rest of it not properly included/reported?

Is there anything I can usefully do in diagnostics terms? I see that there is a dvbsnoop app around for other STBs - but I'm not sure how I'd cross compile it or include it in my buildroot environment.

Not near my dev machine at the moment but been comparing my AVL driver code with that of another DVB device.

Looks like the AVL6211 frontend isn't configured to signal the max and min symbolrates - and because of this TV Headend doesn't know what is valid and what is not, so assumes everything is invalid when you try to manually add a mux...

Compare : AVL 6211
https://github.com/j1nx/buildroot-linux-kernel-m3/blob/master/drivers/amlogic/dvb/avl6211/avlfrontend.c

.info = {
.name = "AMLOGIC DVB-S2",
.type = FE_QPSK,
.frequency_min = 850000,
.frequency_max = 2300000,
.frequency_stepsize = 0,
.frequency_tolerance = 0,
.caps =
FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
FE_CAN_FEC_5_6 | FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
FE_CAN_QPSK | FE_CAN_QAM_16 |
FE_CAN_QAM_64 | FE_CAN_QAM_AUTO |
FE_CAN_TRANSMISSION_MODE_AUTO |
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO |
FE_CAN_RECOVER |
FE_CAN_MUTE_TS
},


With a CX 24116 (ignore the 4 digit numbers - cut and paste from different repos)
http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/dvb/frontends/cx24116.c


.info = {
1478 .name = "Conexant CX24116/CX24118",
1479 .type = FE_QPSK,
1480 .frequency_min = 950000,
1481 .frequency_max = 2150000,
1482 .frequency_stepsize = 1011, /* kHz for QPSK frontends */
1483 .frequency_tolerance = 5000,
1484 .symbol_rate_min = 1000000,
1485 .symbol_rate_max = 45000000,
1486 .caps = FE_CAN_INVERSION_AUTO |
1487 FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
1488 FE_CAN_FEC_4_5 | FE_CAN_FEC_5_6 | FE_CAN_FEC_6_7 |
1489 FE_CAN_FEC_7_8 | FE_CAN_FEC_AUTO |
1490 FE_CAN_2G_MODULATION |
1491 FE_CAN_QPSK | FE_CAN_RECOVER
1492 },


In fact it looks like the AVL6211 driver has been hacked from a DVB-T driver as Guard Interval, QAM 16/64 etc. is a DVB-T thing I thought... I'm guessing that they did a quick and dirty built so that it worked with the DVBPlayer app within Android (which I think this driver code is for) - but it may not be great for other things?

It looks like v4lutils are in the buildroot env I'm using as optional packages so I'm going to add them and see what the fe reports and see if I can scan or zap with them.

Sorry - realised that I didn't mention this in any earlier posts. AVL 6211 is the DVB-S2 chipset in my box. Suggest this issue is probably closed - looks to be more of a driver issue than a TV Headend one. (Unless max/min symbolrates are optional in Frontend capabilities reporting for DVB-S devices?)

Just to update this. I recompiled my kernel with a revised AVL6211 driver with .max and .min symbolrates included in the front-end capabilities. TV Headend now lets me enter valid symbol rates. Can't connect to an LNB this evening. Will report tomorrow whether this has helped or not.

Sorry for commenting on this closed bug, I have a TBS5680 which apparently not is reporting valid symbol rates so I can't enter valid symbol rates, I've contacted TBS about this issue, but can anyone point me in the right direction, code wise in tvheadend, how to workaround this problem for now? The kernel driver structure is unfortunately not as easy as the one mentioned in this thread.