[vdr] [ANNOUNCE] VDR developer version 1.7.24

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Fri Mar 2 11:06:03 CET 2012

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

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.


More information about the vdr mailing list