> 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.
Cheers, Rainer
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
