|
> Date: Mon, 7 May 2012 14:34:57 +0200 > From: vdrportal_midas@xxxxxx > To: vdr@xxxxxxxxxxx > Subject: Re: 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 |
_______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
