Hi guys! My system is currently based on two dvb cards: - Prof 7301 PCI - Prof 8000 PCIe Both of them is using stv090x frontend.
I am using VDR 1.7.31 and i have the following problem: When one adapter has a problem with tuning in epg-scan mode, (eg: frontend 1/0 timed out while tuning to channel...), then the vdr freeze for a while. I can see this while watching tv on the second one (busy) adapter: the xvdr plugin stops feeding xbmc with stream causing buffering and/or artifacts. Another example is that both adapters are in epg-scan mode and i am watching a recording, then every time when i've got "timed out while tuning" in the log, the replay of the recording stops (resulting in a buffering) for a while. When i start vdr with -D0 or -D1 then i've got no problems (but also no 2nd adapter ;)
Is it possible that it is caused by some global lock or mutexes in VDR?
regards,
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 Bialonczyk manio@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 ?
On 01/03/2013 02:09 PM, syrius.ml@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 Bialonczyk manio@skyboo.net writes:
On 01/03/2013 02:09 PM, syrius.ml@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.
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.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
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
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.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
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
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
-
Klaus Schmidinger -
Mariusz Bialonczyk -
Richard Scobie -
syrius.ml＠no-log.org