A tunner that can do turbo can also do normal giving you extra tunner for recording one while watching another. Fake postions ends up adding lots more channels, dupes to take advantage and manual mixing and matching in recording timmers. Better to be able to say which tunners can do a channel and which lnb's to use be they fixed or on a rotor. People with a mix of rotors and fixed lnbs on ku dishes and buds need a matrix system to say where to get what channels and what tuners to use.
----- Original Message ----- From: "VDR User" <user....@gmail.com> To: "VDR Mailing List" <vdr@linuxtv.org> Sent: Friday, October 30, 2009 10:18 AM Subject: Re: [vdr] Restricting a particular dvb card from tuning to channelswith a selected modulation > On Fri, Oct 30, 2009 at 12:11 AM, Theunis Potgieter > <theunis.potgie...@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. > > Best regards, > Derek > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
