On 29.02.2012 21:33, Udo Richter wrote:
Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
- The function cDevice::Receiving() now returns true if there is any
receiver attached to the device. Its boolean parameter has no meaning any more.
Please remember to drop the following line from PLUGINS.html, as it is now finally completely void:
(any negative value will allow a cReceiver to be detached from its cDevice at any time.)
I don't think so. I've rather added the following note:
(any negative value will allow a cReceiver to be detached from its cDevice at any time *in favor of a timer recording or live viewing*).
This was handled via Receiving(true).
This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug.
What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough.
Roughly, the callback should be at the places where these two get called:
DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter);(Thats how VDR's own receivers get out of way.)
There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0) is called, but they are both *after* the final call to GetDevice(). And there is this comment
// only report status if we are actually going to switch the channel
which refers to a change that was made in version 1.1.10:
- Only calling cStatus::MsgChannelSwitch() if a channel is actually going to be switched or has actually been switched successfully (thanks to Stefan Huelswitt).
So before moving the call to cStatus::MsgChannelSwitch() to where it was before version 1.1.10 (which I believe would be what you suggested above) this needs to be given some thought. Personally I wouldn't mind making this change, so if nobody objects, I will.
That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned.
The reason why different devices may be selected here is because when zapping through channels with Up and Down, the first GetDevice() call is done while the current live channel is still active, so the device currently used for live viewing may be avoided because of receivers attached to it. If there is an other device without receivers, but otherwise having the same "impact", that one will be chosen. When the actual SetChannel() call is made, VDR detaches its own receivers from the device and does another GetDevice() call. This time the original live device may be chosen. I don't think that this really is a problem, because a device will always be found, even if temporarily a different one will be preferred. What I really see as a problem here now is that the first call to GetDevice() may call a device's DetachAllReceivers() and the second GetDevice() call may then decide to actually use a different device. I'm currently considering giving GetDevice() another parameter:
static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);
and make it not do any CAM assignments or receiver detachments if Query is true, but only check whether there is any device available.
Klaus