On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote:

You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-)

I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two.

I find this behaviour very irritating in VDR - mainly because of the facts in list thread "Handling of temporarily encrypted channels" recently.

Heikki Manninen schrieb:

On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote:

...

You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-)

I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two.

That's my experience too. My VDR has a Nexus FF card and a Skystar 2 budget card and the only situations I get emergency exits are

1. Bad weather 2. If VDR is used in locations where only one Sat connection is available.

For problem 2 it would be nice if VDR would try other cards first if the card it wants to use for a recording gets no signal before giving up with emergency exit.

Wolfgang

hi,

Steffen Barszus writes:

Shouldn't it be enough to do not sprecify -w option ? :

-w SEC, --watchdog=SEC activate the watchdog timer with a timeout of SEC seconds (default: 0); '0' disables the watchdog

The problem is that the watchdog timer is able to recover from some VDR or VDR+plugin problems, and should have a short timeout, such as one minute, whereas the recording stuff should not have a timeout (unless for some that have buggy drivers).

yours, Jouni

Okay: how to tell my granny, that she can't watch her recording, because some emergency exit is going on? * Hot to tell her, that the sat dish is moving? -> This is nothing for a normal enuser, there must be another solution!

Let me tell you a story: all of our PC's are connected to the internet. Suddenly, the Internet connection is broken down. Now, the PC reboots itself every minute! That’s crazy man! Solve the problem, but do not disturb the whole system.

Last time I had to retune the dish - again the wind problem - it has moved the dish. I was unable with Femon to put it back to work, because VDR constantly rebooted itself and as I am not using a FF card, I always had to restart Xine. Again: this is no sound setup.

When there is a problem, try to fix it .. otherwise we could go directly with software of the richest men in the world. I say: happy blue screen and "reboot is good"!

Please Klaus, I beg you on my knees: make your software useable for "normal" users.

Thanks in advance, Martin

PS: Hunt down those developers of firmware, that make buggy programming. :) I had 10 people sitting around today, trying to watch the movie. All said: wau, what a great system - I will also need a VDR. After 5 Minutes everbody told me its shit - sorry to say that. Well I still know, that it's the best, but all the other 9 are not convinced.

-----Ursprüngliche Nachricht----- Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von Udo Richter Gesendet: Montag, 19. März 2007 00:00 An: VDR Mailing List Betreff: Re: [vdr] VDR stops replay due to strong wind condition

Heikki Manninen wrote:

On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote:

...

You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and

wait

...

until people start complaining because recordings are broken... ;-)

I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two.

Well, at least I will re-enable (or reverse-patch) this feature back into my VDR, as it saved many recordings for me. This fallback is only triggered if a scheduled recording is getting not a single byte of data for at least one minute, so there's IMHO something seriously wrong about it. And in many cases, a clean restart fixes this for me - because for me its usually a malfunction of the tuner / multiswitch communication, and a power down / power up of all LNB power helps.

Cheers,

Udo

_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Udo Richter writes:

into my VDR, as it saved many recordings for me. This fallback is only triggered if a scheduled recording is getting not a single byte of data for at least one minute, so there's IMHO something seriously wrong about

Such as CA authorization needing refreshing, and the card waiting for it. Or bad weather outside.

it. And in many cases, a clean restart fixes this for me - because for

Then you are lucky.

yours, Jouni

In my case driver/firmware problems does cause some problems with FF cards every now and then (usually black screen after boot), but instead of restarting vdr from itself by watchdog, I've made an error monitor script, that monitors syslog, restarts vdr and reloads drivers when error is seen there. This way I get faster reload when needed and can keep watchdog relatively long for some plugins that may cause high load for longer times (had some problems with burn plugin and shorter watchdog time).

2007/3/19, martin martin@air-maxx.net:

Maybe Tero's can give us more input of his error handling script. This sounds a more reasonable way of handling exceptions.

Well basically it is quite simple, but I don't know how well it suites other drivers than dvb-ttpci/av7110.

I've configured vdr as a service which loads/unloads dvb modules and starts/stops vdr. When vdr is started also this small monitor script is started.

Content of monitor script in pseudocode:

put last 30 lines of syslog to tempfile check for errorlines of tempfile with grep if errorline found then service vdr restart exit else sleep 30

Currently I have following patterns specified as errorlines: 'dvb-ttpci: StopHWFilter error' 'dvb-ttpci: StartHWFilter error' 'av7110_send_fw_cmd error'

Thanks Klaus,

For that fast response. As you said: it's not your - respective VDR's Problem. Are there still so many buggy drivers around? I would appreciate to have this work-around-feature disabled by default, but be enabled with a command line option in case somebody still needs it. It's the second time, that I have to ssh my VDR, kill VDR, move my timers away, restart VDR. And as I do not use a full featured card, I also have to start playing again in XINE. It's simply annoying, and you first have to find out why VDR "does not run stable".

Regards, Martin

PS: Disabling this feature in source means that I have to make my own version. It's always extra work that is better spent on making DVB drivers run stable.

-----Ursprüngliche Nachricht----- Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 18. März 2007 15:47 An: vdr@linuxtv.org Betreff: Re: [vdr] VDR stops replay due to strong wind condition

martin wrote:

Hello,

I try to watch recored material with my VDR. This is basically nice, but today we have strong wind. And sorry to get rude, but:

Es ist so zum Kotzen, dass der VDR meint er muss sich neu starten, wenn das DVB-S signal mal nicht so gut ist.

How should I explain my friends that we can’t watch the movie, because the perception of the DVB signal is currently bad. Why does VDR exit, when the signal is bad? It’s not VDR’s Problem, but makes many things different.

Regards,

Martin

Mar 18 15:23:00 htpc vdr: [13541] frontend 0 timed out while tuning to channel 504, tp 112515

Mar 18 15:23:21 htpc vdr: [13541] frontend 0 timed out while tuning to channel 501, tp 112574

Mar 18 15:24:27 htpc vdr: [13541] frontend 0 timed out while tuning to channel 27, tp 112633

Mar 18 15:24:45 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662

Mar 18 15:24:46 htpc vdr: [13541] frontend 0 regained lock on channel 36, tp 112662

Mar 18 15:24:47 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662

Mar 18 15:24:47 htpc vdr: [13541] frontend 0 regained lock on channel 36, tp 112662

Mar 18 15:24:48 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662

Mar 18 15:30:22 htpc vdr: [13543] frontend 1 lost lock on channel 4, tp 111953

Mar 18 15:30:22 htpc vdr: [13543] frontend 1 regained lock on channel 4, tp 111953

Mar 18 15:30:24 htpc vdr: [13541] frontend 0 timed out while tuning to channel 501, tp 112574

Mar 18 15:30:27 htpc vdr: [13538] stopping plugin: streamdev-server

Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: text2skin

Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: epgsearch

Mar 18 15:30:30 htpc vdr: [13548] EPGSearch: Leaving search timer thread

Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: femon

Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: xine

Mar 18 15:30:30 htpc vdr: [13538] timer 58 (4 1507-1600 'Matrix statt Mattscheibe') stop

VDR doesn't know that the signal is bad due to stormy weather. It assumes that something is wrong with the driver and does a restart because you have a timer recording. If there were no recording timer, VDR wouldn't do this.

You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-)

Klaus

_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr