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 or imp |= !device[i]->Receiving() && device[i] != cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice() || ndr // addidtionally prevents matching recording primary-devices