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). > 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. Regards, Frank _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
