Hi,
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 ?
Why ?:
At the moment i'm developing a patch providing alternative channels. An alternative channel is a channel providing the same programme as the original channel, but with another receiving technique (like DVB-T instead of DVB-C). My alternative technique is analoge (via pvrinput). For this, i introduced a new fact "programme is received from an alternative channel". Therefor i have to define the priority of this new fact regarding the impact. So i'd like to know more why the prio is as it is.
Regards, Rainer
Good Morning,
From what I recall of discussions held on this list the reasons are based on, in no particular order :),
First
- initial basic common sense
then an iterative process involving
- satisfaction of common corner use cases - satisfaction of problem use cases - keeping most people happy most of the time - keeping some people happy some of the time
i.e. a can of worms.
I am sure others can provide a more insightful technical response.
Ian.
On 24 Aug 2010, at 06:57, Rainer Blickle wrote:
Hi,
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 ?
Why ?:
At the moment i'm developing a patch providing alternative channels. An alternative channel is a channel providing the same programme as the original channel, but with another receiving technique (like DVB-T instead of DVB-C). My alternative technique is analoge (via pvrinput). For this, i introduced a new fact "programme is received from an alternative channel". Therefor i have to define the priority of this new fact regarding the impact. So i'd like to know more why the prio is as it is.
Regards, Rainer
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
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
Hi,
Am 25.08.2010 08:52, schrieb Rainer Blickle:
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.
a third one (just comes to my mind, not deeply thought about):
Write a device-plugin which provides a new source. Then you will have your own channels. In each channel entry you can configure which "real" channels are behind this and the plugin will attach a receiver to the next free "real" device and passes through the data. That would be a transparent way for recordings, live tv etc. and you don't have to patch vdr (hopefully). You only have to look where to get the epg but I think there's a "copy epg from one channel to another"-patch...
Lars.
Hi Lars,
a third one (just comes to my mind, not deeply thought about):
Write a device-plugin which provides a new source. Then you will have your own channels. In each channel entry you can configure which "real" channels are behind this and the plugin will attach a receiver to the next free "real" device and passes through the data. That would be a transparent way for recordings, live tv etc. and you don't have to patch vdr (hopefully). You only have to look where to get the epg but I think there's a "copy epg from one channel to another"-patch...
i've also thought about such a function. I stopped thinking about this when recognizing the following (an example):
There is a non-ff-device like xineliboutput, softdevice, pvr350 or something like this. Then vdr needs to start the transfer mode. The transfer (cTransferControl resp. cTransfer) object gets attached (i think as a receiver, but perhaps something else). The newly device needs also a transfer object because it is not the device providing the channel. Then there are 2 chained transfer objects.
For Recordings, there is a cRecord object. This record objects receives also the stream from a device. There i need another transfer object, too.
This complexity gets multiplied with more than one receiver (streamdev, liveview, recordings). At this moment, for me this is like rocket science.
There is another, easier way. To introduce such functionality to pvrinput (thats the devices i have and at the moment i'm watching dvb-c channels. if the dvb-c device is in use, i switch to a pvrinput channel). For the (and only for this) channels provided by the pvrinput plugin there is an alternative approach: pvrinput can tune to an analog channel if it is requested for an dvb-c one.
Cheers, Rainer
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
-
Ian Bates -
Klaus Schmidinger -
L. Hanisch -
Rainer Blickle -
Udo Richter