Hi!
Consider the scenario: - 2 devices, 1 used in transfer mode on transponder A - a new recording / streamdev session starts on transponder A
Now, IMO the correct thing to do is start the new receiver in the transfer-moded device, so that the second device is left free.
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.
Attached is a patch for GetDevice() to check for transfer-moded devices as well.
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.
Cheers,
Udo
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.
Can this patch also be applied to vdr-1.5.1 with a little manual fixing? Thanks.
Stone 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.Can this patch also be applied to vdr-1.5.1 with a little manual fixing? Thanks.
I think so, by modifying line 330: imp <<= 1; imp |= !device[i]->Receiving() || ndr; to imp <<= 1; imp |= !device[i]->Receiving() && device[i] != cTransferControl::ReceiverDevice() || ndr;
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
On 04/21/07 16:26, Anssi Hannula wrote:
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
I'm not sure about changing anything in that area in any 1.4 maintenance patch.
If this gets changed at all, it will be in the 1.5 developer version. So please provide a patch for that version, possibly including all the thoughts that have come up in this thread.
Klaus
Klaus Schmidinger wrote:
On 04/21/07 16:26, Anssi Hannula wrote:
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
I'm not sure about changing anything in that area in any 1.4 maintenance patch.
If this gets changed at all, it will be in the 1.5 developer version. So please provide a patch for that version, possibly including all the thoughts that have come up in this thread.
Attached is a patch against 1.5.2. I changed it so that primary devices in local transfer mode are not considered for re-using (I don't know the best behaviour here, just trying to minimize the effects of the patch).
I.e. this patch now affects only non-primary devices: - 2 non-primary devices, one used in transfer mode on transponder A, second free - a new recording / streamdev session starts on transponder A * Before: The new recording starts on the free device. * After: The new recording starts on the already-tuned device.
-
Anssi Hannula -
Klaus Schmidinger -
Stone -
Udo Richter