AW: [vdr] VDR stops replay due to strong wind condition

martin martin at air-maxx.net
Sun Mar 18 18:27:26 CET 2007


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




More information about the vdr mailing list