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). thx Michael _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
