On Fri, Oct 30, 2009 at 12:11 AM, Theunis Potgieter <theunis.potgieter@xxxxxxxxx> 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
