Re: [vdr] Tuning timeouts blocks the other adapter
Klaus Schmidinger wrote: 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? You need to set "EPGScanTimeout = 0". "UpdateChannels" has no effect on automatic tuning. Thanks Klaus, I will give this a try tonight. Regards, Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
On 06.01.2013 05:17, Richard Scobie wrote: 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: 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.0 +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 This would only have an effect when you open a menu of the channel display with a skin that displays the signal strength and quality. If no such menu is open, these functions are never called, and thus disabling them would make no difference. 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? You need to set "EPGScanTimeout = 0". "UpdateChannels" has no effect on automatic tuning. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
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: 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.0 +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 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
Mariusz Bialonczyk writes: > On 01/03/2013 02:09 PM, syrius...@no-log.org wrote: >> I'm not using the xvdr plugin, what would be the equivalent workaround >> for vdr itself ? > > The equivalent in VDR should be this: > http://pastebin.com/raw.php?i=RnW6p5gt Thanks Mariusz ! Giving it a try right now. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
On 01/03/2013 02:09 PM, syrius...@no-log.org wrote: > I'm not using the xvdr plugin, what would be the equivalent workaround > for vdr itself ? The equivalent in VDR should be this: http://pastebin.com/raw.php?i=RnW6p5gt regards, -- Mariusz Białończyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
Mariusz Bialonczyk writes: > 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 Hi, I'm experiencing a similar issue, i have 3 dvb-s cards. I'm not using the xvdr plugin, what would be the equivalent workaround for vdr itself ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
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 regards, -- Mariusz Białończyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr