LNB sharing interrupts recordings with Twinhan DVBS

  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:



Klaus
  

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.
  

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?

Klaus
  

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.
  

Am 09.05.2012 10:45, schrieb Midas:
> 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.
>
>
Ok, i want to add a comment to the bonding workaround and describe some
other strange issues i experienced with lnb sharing recently.

1. The workaround on the one hand helps in that recordings are not
interrupted and liveview does not freeze anymore except maybe if a
recording happens to be on another polarization as already described
before. However the workaround leads to massive problems with initial
tuning. Neither satellite transponder is tuned to (femon does not detect
anything). It seems possible to workaround this by first set the DVBS
devices to have different cables connected in the osd, then switch the
devices via femon plugin and once you have signal then set the devices
back to be connected to one cable. While i am writing this i had to
double apply this workaround to have WDR HD Duisburg in the first run
and TELE5 in the second run which probably was caused by problems with
v/h switching.

Sidenote: The problems with device bonding interrupting live AV and
recordings are clearly not hardware related i would say, as i exchanged
the suspicious Twinhan device with a second DVB-S2 card (Mantis). The
issue also happended in this setup.

2. I got completely confused in how vdr might count devices. As
described i have two satellite and one terrestial device. VDR does
detect four devices in total, which might be explainable by having an
additional device in xineliboutput. Yet though my satellite devices are
recognized first during boot and also recognized as the first two
adapters at vdr start i can only setup lnb sharing cables for device 2
and device 3, which i hardly understand. But the most irritating issue
is that vdr while being on a satellite channel lets me switch dvb
devices via femon between one of the satellite cards and the DVB-T
device...(yet these identifiers are given). On top of that this mostly
coinheres with tuning problems (no signal) and the DVB-T device (again
identified by the string in the femon osd) being the only or first
device that can tune to the channel. These two issues raise the idea
that there is something wrong in device counting inside vdr not
necessarily in femon, i guess.
Imho lnb cables should be possible to set to device 1 and 2 in my setup.
Note that this is in fact offered sometimes yet rarely but if so initial
tuning also works perfectly. As far as i can say this all happens with
both vdr 1.7.21+lnb-sharing and vdr-1.7.27. Atm i am on 27 and i will
post anything new.

I wish i had better facts to describe point 2 yet i am a bit lost how to
reproduce or to understand what is happening at all. If i could be of
further help please drop me a line.

thx

michael
  

Hi,

Am 09.05.2012 16:39, schrieb Midas:
[...]
> 2. I got completely confused in how vdr might count devices. As
> described i have two satellite and one terrestial device.
[...]

  You can try to set the adapter number with the module parameter "adapter_nr", so the devices have the same order on 
every boot. That will remove one possible cause of failure.
  See "modinfo <driver>".

Lars.
  

Am 09.05.2012 19:29, schrieb Lars Hanisch:
> Hi,
>
> Am 09.05.2012 16:39, schrieb Midas:
> [...]
>> 2. I got completely confused in how vdr might count devices. As
>> described i have two satellite and one terrestial device.
> [...]
>
>  You can try to set the adapter number with the module parameter
> "adapter_nr", so the devices have the same order on every boot. That
> will remove one possible cause of failure.
>  See "modinfo <driver>".

i did already. yet the two dvbs cards are still device 2 and 3 in the
device bonding setup in the osd and 0 and 1 in the module params. I will
report if the dvbt/dvbs confusion happens again.

tx

michael