Udo Richter wrote:
> Anssi Hannula wrote:
>> However, the usual "use-already-tuned-devices" check in GetDevice() only
>> checks for device->Receiving(), which does not report transfer-moded
>> device, resulting in the new receiver being started on second device,
>> thus both devices being reserved for receiving data from the same
>> transponder.
> Without taking a deeper look into it right now, I think there was some
> trap with detecting transfer mode in case that some streams are received
> additionally to live mode, for example teletext with osdteletext plugin.
> You may want to double-check this. Changes to GetDevice tend to have
> strange side effects.

I proposed this same patch previously, but it was suggested to instead
of the check for transfer mode to just change the Receiving() to
Receiving(true). I didn't see any caveats back then, so I agreed.
Unfortunately, that resulted in problems with situations that you describe.

However, this original version of the patch does explicitely check for a
device in transfer-mode, and does not care about osdteletext receivers.

What could happen is that this would match the transfer modes whose
receiverdevice() is the primary device itself (some situations related
to the ca or ac3, I guess), thus starting the new receiver in the
primary device, which could cause side-effects if the card's bandwidth
is not wide enough. However, even without this patch, when a recording
is already taking place on the primary device, this rule matches and
another recording could be started on the primary device. I don't know
if we should be preventing these from happening, but if we do, I think
we could make the rule as
imp |= !device[i]->Receiving() && (device[i] !=
cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice()) ||
ndr // prevents matching local-transfer-moded primary-device
imp |= !device[i]->Receiving() && device[i] !=
cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice() ||
ndr // addidtionally prevents matching recording primary-devices

Anssi Hannula

vdr mailing list

Reply via email to