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
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
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
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
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
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
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
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
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
