Re: Impact in cDevice::GetDevice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Am 25.08.2010 08:52, schrieb Rainer Blickle:
This impact algorithm has evolved over time and is a very fragile thing.
Looks like only people have very deep insight in this algorithm should
change it.

For alternate channel, wouldn't it be better to try all possible
channels one after the other until one succeeds? I would not expect
GetDevice to return a device for a different channel than requested.

I have two different solutions in mind.

The first one:
Modify the cDevice::GetDevice method. It returns a device able to
provide the same "semantic" channel as requested ("semantic channel" =
channel with the same programme).
Modify the cDevice::SetChannel method. If the requested channel
couldn't be provided by the device, the method will try to provide the
configured alternatives one.
Pros: The user have the epg and the original channel number on the osd
Cons: Modifies the methods in an unexpected way. Plugins and other
parts of the vdr doesn't work anymore.

The second one:
When pressing CH+/- or selecting an channel directly (via 0-9) and the
selected channel is not available, switch the channel explicit to an
alternative one. (explicit = also display the channel number and the
epg of the alternative channel).
Pros: After switching to the new channel, the vdr is in a clean and
consitent state.
Cons: The vdr has switched to complete another channel when using CH+/-.

Checking for timer conflicts won't work correctly in both ways
(without changes), because this algorithm doesn't know about
alternative channels. But it would be much easier to implement this
when using the second approach.

 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...

Lars.

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux