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

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


vdr mailing list

Reply via email to