On 24.08.2010 21:09, Udo Richter wrote:
> 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.

I also wouldn't like to put additional complexity into GetDevice().
Whatever way an "alternate channel" mechanism is implemented, it
should *not* mess with GetDevice().


> [1] http://www.linuxtv.org/pipermail/vdr/2010-July/023202.html
> [2] http://projects.vdr-developer.org/issues/show/10

vdr mailing list

Reply via email to