Browse files

disabled faulty VDR GetSignalQuality() / GetSignalStrength() functions

using these functions causes freezes on Live TV when the channel scanner
times out on tuning (applies only to systems with more than 1 device)
  • Loading branch information...
pipelka committed Dec 28, 2012
1 parent ad94afc commit d3982714145e392dcf279282b7ece4c49930c51c
Showing with 2 additions and 2 deletions.
  1. +2 −2 src/live/livestreamer.c
@@ -507,8 +507,8 @@ void cLiveStreamer::sendSignalInfo()
int DeviceNumber = m_Device->DeviceNumber() + 1;
- int Strength = m_Device->SignalStrength();
- int Quality = m_Device->SignalQuality();
+ int Strength = 0; //m_Device->SignalStrength();
+ int Quality = -1; //m_Device->SignalQuality();
resp->put_String(*cString::sprintf("%s #%d - %s",
#if VDRVERSNUM < 10728

8 comments on commit d398271

@pipelka Is it temporary? I'm using XVDR with multiple DVB-C cards and never experienced such freeze.


pipelka replied Jan 2, 2013

It's a fact that these freezes are happening without this patch (on some DVB-S2 cards).
I thought it's a VDR bug, but it may also be a kernel/driver issue.
I will change that back (or rewrite it) as soon as the problem is fully located / fixed.

Is there a way to force this behavior somehow, so that I can help with investigation. By the way the used DVB-C cards are using the mantis driver. The only problem with freezes I have is sometimes on channel switching but I didn't expect tuning at this time (usually tuning happens in background I believe)


pipelka replied Jan 2, 2013

I think, it only happens on dual-tuner cards (2 adapters, 1 frontend).

It happens when the epg-scanner tries to tune to an unknown channel:

vdr: [4642] frontend 1/0 timed out while tuning to channel 0, tp 212207

and the GetSignalInfo() function is called during tuning.

The GetSignalInfo() function blocks until the tuning times out, ...


manio replied Jan 2, 2013

I have this issue with two separate cards: Prof7301 and Prof8000 but with the same kernel module used (stv090x).
Not tested yet if this commit fixes this, I'll check it in home.

The easiest way to reproduce it is to put some channels/transponder frequencies in channels.conf which cannot be tuned, so you've got the "timed out while tuning to channel". Next you just start livetv on (using one adapter) and the other is doing epg-scan. Very often when it has problem with tuning then cpu is raising to 100% and you've got a freeze. I was also putting printf's in vdr but i cannot find the cause of the problem.

I also think that the best way to provoke this is to add eg one good channel (for streaming) and the reset several entries in channels.conf which are bad and disable adding new channels in vdr.conf, then i think it should be easy to reproduce, because most of the time the second tuner will be trying to tune to such "bad" frequencies.


pipelka replied Jan 2, 2013

I removed all the "while" loops in the VDR code that where suspicious to me, and the problem still exists.
Currently it looks like a kernel/driver issue.


manio replied Jan 3, 2013

I can confirm that this patch fixes the freezes for me :) I have many timeouts while tuning and none freeze :)
I prefer to watching live tv smoothly then monitoring signal quality with freezing live tv :)
But i still don't know how to fix it - the good news is that you've found the cause of this freezing.


pipelka replied Jan 3, 2013

I came to the conclusion that it's a driver related problem. It also happens if the signal info is directly captured from the device (not via VDR).

But I also know the solution:
Fetching signal information may not be done in the receiver's main loop.
It must be queried be the client (with a message).
This way it doesn't matter if the request times out, ...

I'll do a proof of concept implementation.

Please sign in to comment.