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 cant watch the movie, because the perception of the DVB signal is currently bad. Why does VDR exit, when the signal is bad? Its not VDRs 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