Am 09.05.2012 10:38, schrieb Klaus Schmidinger:
> On 09.05.2012 09:46, Midas wrote:
>> 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.
>
> Was that timer on the same polarization/band as the live view channel?
>
Iirc not. The liveview was H whereas the timer was V.
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
