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(). Klaus > [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
