> 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 firstname.lastname@example.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr