Klaus Schmidinger wrote: > 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... I don't understand what you mean. It just modifies the algorithm to prefer receiving devices on the same transponder that have priority>=0 receivers or transfer mode receivers. Before the patch it would prefer any receiving devices on the same transponder, causing osdteletext receiver to make a difference. Consider scenario - user watches transponder 1 channel 1 through primary FF - recording starts on transponder 1 channel 2 Before this patch: - if osdteletext has a receiver on FF, the recording is made via FF (Receiving(true) is true), otherwise via budget card After this patch: - recording is made via budget card (same behaviour as VDR 1.4.1) The alternative (more logical) fix would be to prefer transponder-tuned primary devices too, so that the recording in above example would be made by FF as it is tuned in the same transponder. But this would probably not be a good idea (at least without YASO) due to the apparent problems with recording via FF. However, one possibility is to prefer the FF for recording in this situation by default (which would leave the budget card free), and also in the original situation (in which the budget has CAM), and have a setup option for Avoiding primary device for recording at all cost. -- Anssi Hannula
