From patchwork Tue May 8 09:57:54 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 12947 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1SRhBB-0005UV-9f for vdr@linuxtv.org; Tue, 08 May 2012 11:58:25 +0200 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtps [TLSv1:AES256-SHA:256] for id 1SRhBA-0004hU-Ff; Tue, 08 May 2012 11:58:01 +0200 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.3/8.14.3) with ESMTP id q489wduS020390 for ; Tue, 8 May 2012 11:58:39 +0200 Received: from [192.168.100.10] (hawk.tvdr.de [192.168.100.10]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id q489vsfv012996 for ; Tue, 8 May 2012 11:57:54 +0200 Message-ID: <4FA8EE22.4090906@tvdr.de> Date: Tue, 08 May 2012 11:57:54 +0200 From: Klaus Schmidinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120306 SUSE/3.1.20 Thunderbird/3.1.20 MIME-Version: 1.0 To: vdr@linuxtv.org References: <662d79-jab.ln1@wuwek.kopernik.gliwice.pl> <4FA4D553.1080506@gmx.de> <4FA539BC.9020503@tvdr.de> <4FA5B7F5.6020403@gmx.de> <4FA6498B.9040009@tvdr.de> <4FA64B98.1010504@gmx.de> <4FA6505E.2080908@tvdr.de> <4FA7C171.7080101@gmx.de> In-Reply-To: <4FA7C171.7080101@gmx.de> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (racoon.tvdr.de [188.40.50.18]); Tue, 08 May 2012 11:58:39 +0200 (CEST) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.8.94515 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MSGID_ADDED_BY_MTA 0.05, ECARD_WORD 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' X-LSpam-Score: -1.1 (-) X-LSpam-Report: No, score=-1.1 required=5.0 tests=BAYES_00=-1.9, RDNS_NONE=0.793 autolearn=no Subject: Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:58:25 -0000 Status: O X-Status: X-Keywords: X-UID: 26193 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 --- 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