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@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 18. M?rz 2007 15:47 An: vdr@xxxxxxxxxxx Betreff: Re: 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
