For DVB-C the problem is correlating the provider with a specific tuner. That is nothing to do with namespace. IMO using namespace for tuner selection is a hack. You need to think of a way to code things so there is an entry in lamedb where a specific tuner or tuner group is selected for a certain provider. e.g. save a tuner mask.
But anyway whoever heard of a cable box that can be set up for 2 providers at the same time? Half the time the hardware makes it impossible anyway. i.e. only one socket on a twin tuner or FBC receiver. IMO it is a nasty hack for something that would almost never get used, and complicating the code for all others.
Possibly.
However, that is how it works for sattelite, and since for both DVB-T and DVB-C the namespace is fake, hardcoded and a hack anyway (with only one purpose, to be able to see that a T or C tuner has to be used), it is therefore logical to extend this hardcoded scheme with a mechanism to be able to select WHICH T or C tuner should be selected, identical to the way an S tuner is selected.
The big question is how, with what, and how do you keep this aligned so channel lists are still interchangable?
It seems again logical to use the sub namespace for this, so images can check for EEEE or FFFF to select T or C, and ignore the sub namespace if they don't want to implement tuner selection. It also solves the EPG problem, as you remove the chance of a duplicate service ref between two C or T providers.
Any other solution requires separate solutions for S and for C/T, a lot more code, changes to lamedb or another structure, and loses compatibility for channel lists. So for me that is a no.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
).
