Dear VDR-experts,
I've been running my VDR for some time now, with basically only one problem left. The setup is budget card only with a Skystar2 card running on kernel 2.6.13 b2c2-flexcop-pci drivers. This outputs to vdr-1.3.34-vanilla (only dvbplayerpatch from Reinhard Nissl) with vdr-xine-0.7.6 (xxmc enabled output to monitor).
The one single problem: at unpredictable moments, VDR-Xine keeps giving the NO SIGNAL message after a channel switch. VDR keeps responding to the remote, reporting channel swithes and menus, but neither video nor audio is displayed anymore (replaying recordings works). A restart of the /etc/init.d/vdr script solves the problem. It seems impossible to predict when it will happens. Fast zapping or slow zapping doesn't seem to trigger the problem.
Is this a timeout problem or the like? And if so how to solve it? Is it the driver or vdr? Anyone clues?
Best regards,
Maarten Wisse
Hi,
Maarten Wisse wrote:
Well, I started my EPIA project with a SkyStar2 Rev. 2.6c about a year ago and replaced the card after 3 months by a NOVA-S for the same reason. About a year ago the driver had the problem that for any reason it didn't get any interrupts anymore and therefore no data for live TV. Reloading the drivers fixed the issue but was anoying.
IIRC, the driver was under havy development (rewrite?) over the year, but it seems that the version in 2.6.13 still has problems. Try multiple
cat /proc/interrupts
to see, whether the device generates any interrupts when it has reached the NO SIGNAL state.
Another idea: could it be a temperature issue which lets the device freeze at some point so that only a reset (= reloading of drivers) can force it back to life?
Bye.
As I said in my reply to Tony, I do not need to reload my drivers. After reloading vdr, everything works ok. So it seems more of the EPG timeout problem you mentioned in your other post.
I'll do that.
No, I don't need to reload, and as far as I know, temperature is very low inside the case. I've tried it on the back of the card, but I've never felt high temperature there.
Best,
Maarten
Le lundi 14 novembre 2005 à 20:53 +0100, Maarten Wisse a écrit :
It is the card losing interrupts but this was fixed after 2.6.11 kernel on my machine. I am running FC4 kernels now.
It is a xine problem because VDR will still record in this state. Now I have xine showing NO SIGNAL after long periods of inactivity because SetPlayMode: switched to 0. Just zapping to a channel wakes xine.
Cheers
Tony
Hi,
tony wrote:
But this is a different problem. Looks like VDR does an EPG scan.
Just have a look into your syslog for a line like this (in english):
Nov 14 00:06:31 video vdr[31630]: info: Beginne mit EPG-Scan
You may also set EPG timeout to 0 to disable automatic EPG scans. You'll see a similar behaviour if you start an EPG scan manually.
Bye.
Le lundi 14 novembre 2005 à 22:59 +0100, Reinhard Nissl a écrit :
You may also set EPG timeout to 0 to disable automatic EPG scans. You'll see a similar behaviour if you start an EPG scan manually.
They are set to off in both VDR and vdradmin but that does not stop them from running...
Tony
My syslog is at verbosity level 3 and it does not display such a line.
You may also set EPG timeout to 0 to disable automatic EPG scans. You'll see a similar behaviour if you start an EPG scan manually.
How to start a manual epg scan? The epg timeout was 5. I've set it to 8 now, because I like to have automatic epg scans, and the problem does occur only every now and then. Is, given these presuppositions, increasing the number the right way, or should I decrease it instead?
Best,
Maarten
Hi,
Maarten Wisse wrote:
In VDR's EPG menu press the red button.
I've set this to 1 on my test system and after 60 minutes, an EPG scan kicks in. The EPIA VDR is set to 3 and there is no problem to watch movies with a length of 150 minutes.
@tony: If you are a little bit familar with debugging, I'd suggest to apply the following patch to vdr-xine-0.7.6's xineDevice.c:
--- ../xine-0.7.6/xineDevice.c 2005-09-11 21:17:06.000000000 +0200 +++ xineDevice.c 2005-11-16 21:44:35.000000000 +0100 @@ -80,6 +80,16 @@ namespace PluginXine
bool cXineDevice::SetPlayMode(ePlayMode PlayMode) { + { + time_t t1 = time(0); + static time_t t0 = t1; + + if (0 == PlayMode && (t1 - t0) > (30 * 60)) + *(char *)0 = 0; + + t0 = t1; + } + ptsV = ptsA = ptsP = ptsD = -1;
ts = 0;
This let's VDR crash when a SetPlayMode(0) happens, but only if the last SetPlayMode() call was more than 30 minutes in the past.
To get a usefull backtrace, make sure that VDR and all plugins are compiled with the -g compiler switch. If you want to have useful variable values in the backtrace, switch off optimizing with -O0. I compile my VDR test system with -g3 -O0.
You may enable the creation of coredumps with
ulimit -Sc unlimited
Then use a debugger to analyze the coredump, e. g. for ddd:
ddd /path/to/vdr /path/to/core
From the menu select the backtrace window and have a look at the call stack.
Bye.
I've tried that now, but that yields different results. Indeed, after pressing the red button, the NO SIGNAL appears, but pressing channel up or down, the signal will appear again. I don't need to restart vdr in this case, which I need when the NO SIGNAL screen appears accidentally. So, my problem must still be different.
Best regards,
Maarten
It is the card losing interrupts but this was fixed after 2.6.11 kernel on my machine. I am running FC4 kernels now.
As far as I can see, it is not a driver problem in my case, given that a restart of vdr suffices to get the problem solved. I don't need to reload my drivers.
I've never seen this problem on my box.
Thank you for posting anyway.
Best regards,
Maarten
-
Maarten Wisse -
Reinhard Nissl -
tony