Am 24.08.2010 07:57, schrieb Rainer Blickle:
> in the method cDevice::GetDevice the device with the least impact is
> searched (the block with "imp <<= x; imp |= "). For calculating the
> impact (higher value = bigger impact) some "facts" are used.  The most
> prio fact is "prefer the primary device for live viewing", the least
> prio is "prefer CAMs that are known to decrypt this channel".
> Does anyone know why the facts are ordered in this way ?

This impact algorithm has evolved over time and is a very fragile thing.
Its quite difficult to oversee all consequences these rules have, and
they're not completely bug-free either, see for example [1] and [2].

Part of the problem is that the whole priority system is not very
consequent: Live view on primary devices leaves the device with 0
receivers attached like its unused, live view transferring to output
devices has priority -1 but is treated like priority Setup.PrimaryLimit,
re-tuning live-view to a different channel disconnects a stream with
same priority while timers cannot disconnect streams with same priority,
and so on.

I think, if my proposed change [2] gets applied, some of the impact
rules may be even superfluous, but I'm not very sure. In the end,
changes to the impact algorithm often resulted in unexpected side
effects in the past.

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.




vdr mailing list

Reply via email to