hi,
I agree this is a off-topic... (but I hope on topic for the mailing
list anyway)
Reinhard Nissl writes:
> The use of MAXBROKENTIMEOUT is a last resort of getting a recording
> recorded when for example the driver or hardware is in a state where
> only reloading the driver can help out of
Hi,
Jouni Karvo wrote:
>> 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 time. So
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
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,
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
