From patchwork Sun Jan 6 04:17:28 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Scobie X-Patchwork-Id: 16142 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1TrhY2-0000zJ-LU; Sun, 06 Jan 2013 05:09:22 +0100 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1TrhXc-0000yv-Gw for vdr@linuxtv.org; Sun, 06 Jan 2013 05:09:21 +0100 X-tubIT-Incoming-IP: 203.97.33.64 Received: from smtp3.clear.net.nz ([203.97.33.64]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtp for id 1TrhXb-0006fO-Ci; Sun, 06 Jan 2013 05:08:56 +0100 Received: from mxin1-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MG600KA8RIMR930@smtp3.clear.net.nz> for vdr@linuxtv.org; Sun, 06 Jan 2013 17:08:48 +1300 (NZDT) Received: from 210-246-8-90.paradise.net.nz (HELO [210.246.8.90]) ([210.246.8.90]) by smtpin1.clear.net.nz with ESMTP; Sun, 06 Jan 2013 17:08:46 +1300 Date: Sun, 06 Jan 2013 17:17:28 +1300 From: Richard Scobie In-reply-to: <50E528E2.6080104@skyboo.net> To: VDR Mailing List Message-id: <50E8FAD8.1040701@clear.net.nz> MIME-version: 1.0 References: <509D8DFA.8090608@skyboo.net> <50E528E2.6080104@skyboo.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.6.40031 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, ECARD_WORD 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __INT_PROD_TV 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __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] Tuning timeouts blocks the other adapter 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: , Sender: vdr-bounces@linuxtv.org Errors-To: vdr-bounces@linuxtv.org Mariusz Bialonczyk wrote: > On 11/10/2012 12:12 AM, Mariusz Bialonczyk wrote: >> Is it possible that it is caused by some global lock or mutexes >> in VDR? > > Hello > It seems the cause of the problem has been located by Alex Pipelka. > > The vdr freezes occurs when obtaining the signal strength/quality > with functions SignalStrength() and/or SignalQuality() > and when non-busy adapter has tunining issues > (frontend x/x timed out while tuning to channel ...). > It occurs only on multi adapters systems (one adapter is doing > EIT scan and the other is used, eg for a live-tv). > > Guys, any thoughts on this? > I think it may be even kernel/drivers related issue. > > some details in commit discussion: > https://github.com/pipelka/vdr-plugin-xvdr/commit/d3982714 I am running vdr 1.7.34 with a TT S2 6400 card on a dual core Intel Atom 1.8GHz board and believe I may be seeing these issues. They manifest as intermittent video/audio disturbances of less than one frame duration - the audio usually gives a "squawk". I tried adding the suggested patch to vdr in the above thread: It's possible it has improved the situation - no longer getting audio disturbances, but there are still very short duration video glitches. In an effort to eliminate the second tuner scanning empty channels as the cause, I set, "UpdateChannels = 0" in setup.conf, but it appears to not have the desired effect: Jan 6 16:47:27 atom vdr: [790] frontend 1/0 timed out while tuning to channel 487, tp 212651 Jan 6 16:47:47 atom vdr: [790] frontend 1/0 timed out while tuning to channel 124, tp 212671 Jan 6 16:48:08 atom vdr: [790] frontend 1/0 timed out while tuning to channel 71, tp 212680 Jan 6 16:48:50 atom vdr: [790] frontend 1/0 timed out while tuning to channel 110, tp 112280 Is there some way I can stop the unused tuner from scanning altogether? Regards, Richard diff -ur vdr-1.7.35-org/dvbdevice.c vdr-1.7.35/dvbdevice.c --- vdr-1.7.35-org/dvbdevice.c 2012-12-30 12:27:39.000000000 +0100 +++ vdr-1.7.35/dvbdevice.c 2013-01-03 14:34:30.997489765 +0100 @@ -1510,12 +1510,12 @@ int cDvbDevice::SignalStrength(void) const { - return dvbTuner ? dvbTuner->GetSignalStrength() : -1; + return -1; } int cDvbDevice::SignalQuality(void) const { - return dvbTuner ? dvbTuner->GetSignalQuality() : -1; + return -1; } const cChannel *cDvbDevice::GetCurrentlyTunedTransponder(void) const