Anssi Hannula wrote: > Klaus Schmidinger wrote: >> Anssi Hannula wrote: >>> >>> 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. Attached is a patch which has this approach. So after *this* patch the above quoted scenario would continue like this instead: - recording is made via budget card (same behaviour as VDR 1.4.1) if AvoidPrimaryDevice is set - recording is made via FF card (leaving budget free) if AvoidPrimaryDevice is not set. Also if AvoidPrimaryDevice is set, budget with CAM would be preferred over non-CAM FF for recording FTA channels in the original situation. -- Anssi Hannula -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.4.1-5-getdevice-alt.diff Type: text/x-patch Size: 3372 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20060826/20b9bafe/vdr-1.4.1-5-getdevice-alt.bin
