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. Cheers, udo [1] http://www.linuxtv.org/pipermail/vdr/2010-July/023202.html [2] http://projects.vdr-developer.org/issues/show/10 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
