Hi Lars, > a third one (just comes to my mind, not deeply thought about): > > Write a device-plugin which provides a new source. Then you will have your > own channels. In each channel entry you can configure which "real" channels > are behind this and the plugin will attach a receiver to the next free > "real" device and passes through the data. That would be a transparent way > for recordings, live tv etc. and you don't have to patch vdr (hopefully). > You only have to look where to get the epg but I think there's a "copy epg > from one channel to another"-patch... i've also thought about such a function. I stopped thinking about this when recognizing the following (an example): There is a non-ff-device like xineliboutput, softdevice, pvr350 or something like this. Then vdr needs to start the transfer mode. The transfer (cTransferControl resp. cTransfer) object gets attached (i think as a receiver, but perhaps something else). The newly device needs also a transfer object because it is not the device providing the channel. Then there are 2 chained transfer objects. For Recordings, there is a cRecord object. This record objects receives also the stream from a device. There i need another transfer object, too. This complexity gets multiplied with more than one receiver (streamdev, liveview, recordings). At this moment, for me this is like rocket science. There is another, easier way. To introduce such functionality to pvrinput (thats the devices i have and at the moment i'm watching dvb-c channels. if the dvb-c device is in use, i switch to a pvrinput channel). For the (and only for this) channels provided by the pvrinput plugin there is an alternative approach: pvrinput can tune to an analog channel if it is requested for an dvb-c one. Cheers, Rainer _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
