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
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
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 ma...@skyboo.net 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 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 ma...@skyboo.net 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
