> 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
This complexity gets multiplied with more than one receiver
(streamdev, liveview, recordings). At this moment, for me this is like
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.
vdr mailing list