[vdr] [ANNOUNCE] VDR developer version 1.7.24

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Tue Feb 28 10:11:48 CET 2012

On 28.02.2012 09:32, Frank Schmirler wrote:
> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
>> On 27.02.2012 14:33, Frank Schmirler wrote:
>>> I suggest the following additional changes:
>>> - instead of any negative priority, only priority -MAXPRIORITY gets the
>>> special meaning of "may be detached anytime"
>>> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
>>> not all plugins have to be updated to keep their previous behaviour
>>> - use LIVEPRIORITY-1 as priority for cTransfer
>>> I can't however overlook the impact these modifications have.
>> Me neither - and that's why I strongly oppose them ;-)
> Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's
> more obsolete stuff which can be thrown overboard. I feel it's time to start
> from scratch with the device selection code, keeping also the new challenges
> in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).

That's surely something I'm going to lok at after version 2.0.

>> What exactly is the use case for this, anyway?
>> VDR has two purposes: "live view" and "recording". And the current
>> priority scheme handles this pretty well IMO.
> I guess in the meantime you could add "network streaming" to the list of
> purposes, too. There are a lots of people using streamdev out there for
> VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the
> VDR-to-VDR-Streaming part is challenging. The easy case is a headless server
> somewhere in the attic. No need to care about live TV. But some people's
> "server" is their main VDR in the living room and they usually want clients
> with a priority which is lower than local live TV. That's the use case.
> At the moment it all works pretty well in streamdev, but the whole thing is
> quite fragile with respect to API changes, time-consuming to maintain (e.g. an
> almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with
> VDR main thread for switching LiveTV). So it's not that streamdev depends on
> Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to
> get rid of some of the most ugly workarounds in the long run. The patch would
> have been a big step into that direction. Still, for a nice solution some more
> (but probably much less dramatic) modifications in the VDR core would be
> necessary.

I'll keep this in mind for "after version 2.0".


More information about the vdr mailing list