Am 06.05.2012 11:51, schrieb Klaus Schmidinger:
> On 06.05.2012 01:29, Midas wrote:
>> Am 05.05.2012 16:31, schrieb Klaus Schmidinger:
>>> On 05.05.2012 09:22, Midas wrote:
>>>> Hi there,
>>>> i have two satellite devices in an lnb-sharing setup. As said in the
>>>> topic since update to vdr 1.7.27 recordings do not put data on the
>>>> disk
>>>> anymore and AV liveview with the vdr-sxfe frontend freezes if bonding
>>>> sets the Twinhan Card to master.
>>>> The setup is Technisat Skystar HD and KWorld DVBS Satellite Card
>>>> (clone
>>>> of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27.
>>>> I have been using vdr 1.7.21 before with lnb-sharing applied. In
>>>> the old
>>>> setup there was a similar problem in that switching to vertical didn't
>>>> work reliably or at all respectively. I managed to overcome this
>>>> behaviour by patching the Twinhan driver to eliminate _any_ voltage
>>>> output on the card. Once i found a working patch vdr has been running
>>>> for months without any problems anymore.
>>>> Note that the 'new' issue occurs with the vanilla Twinhan driver
>>>> and my
>>>> patched version as well.
>>>> Is it maybe possible to force the use of one card as Master bonding
>>>> device or does anyone have other ideas to overcome the problems?
>>> If the master of a set of bonded devices doesn't get a signal, VDR
>>> should automatically switch the master to the next of the bonded
>>> devices.
>>> See cDvbTuner::Action(), case tsTuned:
>>>    if (bondedTuner&&  bondedMaster)
>>>       bondedMasterFailed = true; // give an other tuner a chance in
>>> case the sat cable was disconnected
>>> Of course, making sure the devices work properly in the first place
>>> might be a good idea ;-)
>> Do i get the term Master wrong? Master in my assumption should be the
>> device where the liveview signal comes from unless there is a recording
>> in which case the device tuned to the recording transponder should be
>> Master.
> In the context of device bonding "master" means the device that actually
> controls the LNB (either trough voltage/tone or DiSEqC). It has
> nothing to
> do with whether this device is used for live view or recording.
>>  In the first case the slave cannot steal the tuning parameters
>> to prevent breaking liveview whereas in the second the liveview slave
>> cannot interefere with the ongoing recording.
>> Concerning my issue the ongoing search for transponders on the
>> non-liveview device seems to break with the liveview device which should
>> not happen. Yet in case of recordings i am bit unsure what interferes
>> with what. I am also still unsure if it is a driver or lnb sharing issue
>> though the v/h issue in my former setup points to the first case at
>> least for a certain kind.
>> Do i conclude right, setting the bondedMasterFailed to false in the
>> switch construct would be a dirty hack to workaround my bogus setup?
> I'm not sure about that.
> I would suggest you use VDR with only one single device at a time and
> make sure it can receive all polarizations and bands. If a device or
> driver fails to deliver that, you should try to fix it. VDR assumes that
> a device actually works ;-)

Just to add this missing info: Both devices work perfectly in a single
device setup. Both devices were even capable in the former 1.7.21 dual
device setup (with my patch).



vdr mailing list

Reply via email to