Re: [vdr] Understanding how vdr's tuning algo works.

2007-03-09 Thread Jouni Karvo
hi, Reinhard Nissl writes: > it will take 37000+ ms until VDR receives the stream. In the case of a > recording, this is simply to long as recorder.c defines a > MAXBROKENTIMEOUT of 30 seconds. VDR's recorder considers a stream to be > broken when it doesn't receive a PES packet for that tim

Re: [vdr] Understanding how vdr's tuning algo works.

2007-03-09 Thread Luca Olivetti
En/na Stone ha escrit: 3) Does vdr care or know anything about a rotor setup where the channel isn't always present the moment the diseqc commands are sent? Well, vdr isn't aware the dish is moving, so it doesn't wait for it. This isn't a big problem for live view, but it is a potential probl

Re: [vdr] Understanding how vdr's tuning algo works.

2007-03-09 Thread Reinhard Nissl
Hi, Stone wrote: >I am curious how vdr's tuning algorithm, in general, works. With all > the refactoring that has gone on with how vdr tunes, locks, retunes, and > otherwise tries to anticipate various forms of interference, storms, or > other activities that could hinder vdr from performing

[vdr] Understanding how vdr's tuning algo works.

2007-03-09 Thread Stone
Hello All, I am curious how vdr's tuning algorithm, in general, works. With all the refactoring that has gone on with how vdr tunes, locks, retunes, and otherwise tries to anticipate various forms of interference, storms, or other activities that could hinder vdr from performing its job adequit

Re: [vdr] Handling of temporarily encrypted channels

2007-03-09 Thread Klaus Schmidinger
Ondrej Wisniewski wrote: > Ondrej Wisniewski wrote: >> >> So I propose that VDR should always tune to a channel that is requested, >> get the current CA value from the data stream (and not from the >> channels.conf) and then decide if the channel can be shown/recorded. >> Does that sound like a goo

Re: [vdr] Handling of temporarily encrypted channels

2007-03-09 Thread Klaus Schmidinger
VDR User wrote: > Why should VDR crash at all? If the CA value changes, just check if it > can be decrypted. If so, continue recording, if not then stop > recording. Whatever the case I just don't see a logical reason for VDR > to panic-exit or whatever. If the CA value of a channel that is cur

Re: [vdr] Handling of temporarily encrypted channels

2007-03-09 Thread VDR User
Why should VDR crash at all? If the CA value changes, just check if it can be decrypted. If so, continue recording, if not then stop recording. Whatever the case I just don't see a logical reason for VDR to panic-exit or whatever. I agree, it's a pretty serious problem and many of my timers wer

Re: [vdr] Vdr or driver performance dropout

2007-03-09 Thread Marko Mäkelä
On Sat, Mar 03, 2007 at 10:12:21PM +0200, Kartsa wrote: > I did a seven minute session where I had 5 test recordings which started > one minute apart and ended at the same time. After each recording had > started I tested the responce of remote by just pussing menu button. > After three recordin

Re: [vdr] Handling of temporarily encrypted channels

2007-03-09 Thread Ondrej Wisniewski
Ondrej Wisniewski wrote: So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks? @K