Anssi Hannula wrote:
Anssi Hannula wrote:
Klaus Schmidinger wrote:
In this particular case I guess the recording really shouldn't
start on the primary card, because the osdteletext plugin isn't
a "real" recording process.
So how shall we distinguish between cReceivers that do actual
recordings and such that just receive, e.g., teletext data?
Or those that receive a radio channel for streaming it to
a remote client? Where's the limit?
Hm, every cReceiver which doesn't receive critical data has -1 priority.
The only exception is the transfer-mode, which has -1 too.
And here's the patch.
------------------------------------------------------------------------
diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c
--- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300
+++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300
@@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann
// to their individual severity, where the one listed first will make
the most
// difference, because it results in the most significant bit of the
result.
uint imp = 0;
- imp <<= 1; imp |= !device[i]->Receiving(true) || ndr;
// use receiving devices if we don't need to detach existing receivers
+ imp <<= 1; imp |= !device[i]->Receiving() && device[i] !=
cTransferControl::ReceiverDevice() || ndr; // use receiving devices if we don't need to detach
existing receivers
imp <<= 1; imp |= device[i]->Receiving();
// avoid devices that are receiving
imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice();
// avoid the Transfer Mode receiver device
imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0),
0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values
-99..99 can be used)
Wouldn't this also avoid a non-primary device if the transfer mode
is coming from there? I don't think that would be good...
Klaus
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
