[vdr] [ANNOUNCE] VDR developer version 1.7.24

Frank Schmirler vdr at schmirler.de
Fri Mar 2 18:20:49 CET 2012


On Fri, 02 Mar 2012 13:01:23 +0100, Klaus Schmidinger wrote
> On 02.03.2012 12:54, Frank Schmirler wrote:
> > On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
> >> On 01.03.2012 09:38, Frank Schmirler wrote:
> >>> On Wed, 29 Feb 2012 21:33:31 +0100, 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.)
> >>>>
> >>>> 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.
> >>>
> >>> Wouldn't it help to run those live related receivers with priority
> >>> IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority
> >>> IDLEPRIORITY?
> >>
> >> Wouldn't that get us back to square one? ;-)
> >
> > Well, no. Previously live TV and related receivers were treated the same way
> > (same priority, both handled as if they were not present). Currently we have
> > different priorities (-1 and -99) and both are not ignored. So the -99
> > receiver is not in the way when switching live TV, but it will have an impact
> > on device selection. Ignoring receivers with IDLEPRIORITY (or likewise
> > MINPRIORITY) would solve this.
> 
> But where would that be different from the previous version, where
> all receivers with negative priorities have been ignored?
> Now I'm confused...

Currently there's no such thing like a "live TV related receiver" (like for
the osdteletext-plugin). A "live related receiver" will always follow the
current live channel. So it shouldn't be in the way when switching channels
and will probably never show up alone but always in company with the live TV
transfer mode receiver.

VDR up to 1.7.24 had transfer mode receiver at priority -1, live related
receivers at -1. All negative priorities treated the same way, i.e. either
totally ignored or not ignored at all. No black screen in transfer mode when a
recording starts as the transfer mode receiver at -1 is not ignored
(Receiving(true) in ProvidesChannel()). But for the same reason a live related
receiver at -1 (or any other negative priority) isn't detached when the live
channel is being switched. The same problem would also apply to low priority
"remote transfer mode" receivers.

The current state of the patch has transfer mode receiver at priority -1, live
related receivers by default at -99. No receivers are ignored. Black screen in
transfer mode when a recordings starts? Don't know if it's back but I assume
the impact in GetDevice takes care of it. The live related receiver is still
attached when switching live TV, but it no longer blocks the channel switch
due to its lower priority. So low priority "remote transfer mode" should be
fine, too. However the live related receiver isn't totally ignored.
Receiving() will detect it an so it e.g. has an impact on device selection
which is even higher than NumProvidedSystems().

Now lets assume, Receiving() would ignore a receiver at either IDLEPRIORITY or
MINPRIORITY. Black screen? Still don't know ;). Live related receiver? Still
attached when switching live TV and still not in the way due to low priority.
Same for "remote transfer mode". But now Receiving() no longer reports it, so
no impact on device selection. The boolean parameter of Receiving() must still
be ignored of course.

Moving cStatus::MsgChannelSwitch(this, 0) and plugins with "live related
receivers" reacting to it by detaching the receiver should achive the same.

Cheers,
Frank




More information about the vdr mailing list