[vdr] Restricting a particular dvb card from tuning to channels with a selected modulation
user.vdr at gmail.com
Fri Oct 30 18:18:11 CET 2009
On Fri, Oct 30, 2009 at 12:11 AM, Theunis Potgieter
<theunis.potgieter at gmail.com> wrote:
> Does the sourcecap patch not address this whole issue? Even if source
> cap or something similar is applied, how will VDR be able to tune to a
> 8psk turbo-fec type channel if v4l2 does not provide any support for
> it? It shouldn't be VDR's responsibility surely? unless 8psk turbo-fec
> becomes part of the new dvb-plugin archtitecture of future VDR.
Turbo fec isn't specified in the stream or in v4l, it's only reported
as 8psk. I may be wrong but doesn't sourcecaps only assign devices to
orbital positions? What happens about all the orbital positions that
contain both qpsk and 8psk turbo? It was suggested that you make a
fake orbital position for those with 8psk turbo transponders, then
change your channels.conf & sources.conf accordingly.
Consider the following:
dvb devices being used: budget dvb-s, genpix dvb-s (supporting turbo
fec), twinhan dvb-s/s2
sat1 tp1 (qpsk) dvb-s
sat1 tp2 (8psk turbo) dvb-s
sat2 tp1 (qpsk) dvb-s
sat2 tp2 (8psk turbo) dvb-s
sat2 tp3 (qpsk) dvb-s
sat3 tp1 (8psk) dvb-s2
If you say sat1 should use the genpix because it has an 8psk turbo fec
tp then you restrict the budget and twinhan ability to tune the qpsk
on tp1. Same for sat2.
If you want to tune sat3 tp1 by asking the devices 'are you s2
capable?' then you get a false hit by the genpix, which lies about
being s2 capable (so it can provide 8psk).
If you use sourcecaps and create a fake orbital position for sat1 tp2
and sat2 tp2 then it works but requires the user to create fake data
and do more work.
You can see simply doing a capability query is not good enough because
it can return unreliable results. This isn't VDR's fault, it's v4l &
drivers but it can still be easily addressed within VDR which giving
the user other advantages such as assigning certain devices to certain
channels/transponders because they (maintain) lock better.
Now consider you just simply add support for an optional file called
override.conf (or whatever). This file could look like this:
<channel>:<list of devices to use>
100:1,3 means for channel 100 use only devices 1 and 3.
101:2 means for channel 101 use only device 2.
You could also add support for orbital positions with:
<orbpos>:<list of devices to use>
S100.0:2,3 means for orbital position S100.0 use only devices 2 and 3.
S109.0:3 means for orbital position S109.0 use only device 3.
So you see, simply doing a capability query is not enough because it
can be unreliable. Using sourcecaps can solve the problem but
requires non-existent orbital positions to be created and maintained
in both channels.conf and sources.conf. By adding an override.conf,
you can give full control to the user by using one simple _optional_
file. This seems like the easiest & best with the most flexibility
for the user. It solves _everyones_ needs and doesn't require false
data, patching, etc. As mentioned before you can also write a simple
shell script to auto-generate the override.conf for you. I know Klaus
doesn't like to add files but if the file is optional and adding
support for it means satisfying everyones needs, I can't see a good
argument against it. Especially when the alternative requires at
least some users to add fake data in their channels.conf+sources.conf.
More information about the vdr