Am 08.05.2012 11:57, schrieb Klaus Schmidinger:
> On 07.05.2012 14:34, Midas wrote:
>> 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).
>
> Looks like this comes from the "bondedMasterFailed" mechanism, which
> switches
> the master to an other device if one fails. Apparently this disturbs
> live viewing
> or recordings if a channel can't be tuned to in the EPG scan (or
> otherwise).
>
> Since the whole device bonding (formerly known as "LNB sharing") is a
> makeshift
> solution, anyway, I guess putting in that bondedMasterFailed mechanism
> was just
> too much of a good thing. I guess it will be better if I just drop that.
>
> Please try whether the following change fixes your problem:
>
> --- dvbdevice.c 2012/04/04 09:49:12 2.70
> +++ dvbdevice.c 2012/05/08 09:49:11
> @@ -878,9 +878,6 @@
> isyslog("frontend %d/%d timed out while tuning
> to channel %d, tp %d", adapter, frontend, channel.Number(),
> channel.Transponder());
> lastTimeoutReport = time(NULL);
> }
> - cMutexLock MutexLock(&bondMutex);
> - if (bondedTuner && bondedMaster)
> - bondedMasterFailed = true; // give an other
> tuner a chance in case the sat cable was disconnected
> continue;
> }
> WaitTime = 100; // allows for a quick change from
> tsTuned to tsLocked
>
>
It seems to work :). I tried for half a day and no issue happened, yet
at a distinct timer start the liveview was not switched and froze but
the timer correctly started and recorded the whole show.
Afterwards i changed my setup and exchanged the Twinhan DVBS with a
Mantis DVBS2 card. I am observing other issues with lnb sharing now and
will start a new thread once i know a bit better what is happening.
Sorry to have no better news at this point.
Thank you Klaus.
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
