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:



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