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)
vdr mailing list