> Date: Mon, 7 May 2012 14:34:57 +0200
> From: vdrportal_midas@gmx.de
> To: vdr@linuxtv.org
> Subject: Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
>
> Am 06.05.2012 12:20, schrieb Klaus Schmidinger:
> > On 06.05.2012 11:59, Midas wrote:
> >> 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).
> >
> > Well, then please post your exact setup together with a step-by-step
> > set of instructions on how to reproduce the problem. Maybe I can
> > reproduce
> > it here on my system.
> >
> > Klaus
>
> Thank you Klaus for your offer and your effort.
>
> I guess this is one of the bugs (not necessarily a vdr one!) which are
> relativley hard to track. Yesterday i have reproduced the issue with a
> vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize
> potential bug sources. I did not observe any changes, the issue still
> appears.
>
> My setup:
>
> debian squeeze
> self-built Kernel 3.0.4
> media-build git20120504
> vdr 1.7.27
> Technisat Skystar HD (PCI DVB-S2) -> clone of and recognized as
> Technotrend S-3200 (stb0899)
> KWorld DVB Satellite card -> clone of Twinhan VP1020 (PCI DVB-S)
> WinTV Nova T-Stick (USB DVB-T)
> xineliboutput cvs20120415
> vdr-sxfe with vdpau on a 8400 GS PCIE
> nvidia driver 295.40
>
> Satellite setup:
> One satellite cable that is being distributed with a splitter (diode
> protected). No priority circuit afaik. In vdr both devices are set to be
> connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird
> 13.0E are receivable. The rest of the setup remains unclear yet most
> likely the cable goes to a switch or something though surely not
> directly into the lnb.
>
> Symptoms:
> AV signal sometimes stops while watching a DVB-S(2) channel (T not
> tested). Concerning the log this most likely happens when vdr fails to
> tune to a channel while scanning for new transponders in the background.
> Device bonding then tries to make another tuner tune to this channel
> which in this case obviously is the liveview device.
> This not only freezes the liveview AV but also makes recordings stop to
> write data on the disc though still being shown as recording in the vdr
> osd. Note that the liveview AV signal can be reactivated by switching to
> another channel. However this does not revive a recording. (Unsure: If i
> recollect correctly it is even possible to switch to channels which
> should not be allowed to switch to because of the active timer.)
>
> How to reproduce:
> Install vdr 1.7.27, start watching a channel. After minutes the av
> signal freezes and the log tells us that device bonding has switched the
> master.
>
> (Superstition: There is an imho very small chance this can be triggered
> by cpu load which might point to setup probs. I observed the issue once
> when i called the osd and in another case when i started compiling the
> media build drivers).
>
> Greets
>
> Michael
>
Here i have 3 devices in a bonding setup (without diseqc) / vdr-1.7.26. i have similar symptoms --> av-freezes.
If i switch to another receiver (via femon) or another channel, av comes back. i have to dig deeper into the symptoms.
Markus