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