Motorised dish tuning delays and vdr
Commit Message
Seppo Ingalsuo wrote:
> Hi,
>
> Have you seen problems in getting picture after first channel change
> which requires dish movement?
>
> I'm controlling motorized dish directly trough diseqc.conf without rotor
> or actuator plugins. I didn't have problems with earlier VDR 1.3.x
> versions. Since upgrading from linux 2.6.9 to 2.6.11 I have seen
> occassionally similar problems even with DVB-T when new channel is on
> different frequency (multiplexes A, B, C).
>
> What is the corrent place to experiment with VDR tuning timeout values?
As a stop-gag measure, while core vdr is properly adapted to steerable
dishes (Klaus, you promised it ;-), you can use the attached patch. What
it does is explained at
http://linuxtv.org/vdrwiki/index.php/Actuator-plugin#Patches
Bye
Comments
Luca Olivetti wrote:
>
> As a stop-gag measure, while core vdr is properly adapted to steerable
> dishes (Klaus, you promised it ;-), you can use the attached patch.
> What it does is explained at
> http://linuxtv.org/vdrwiki/index.php/Actuator-plugin#Patches
>
Thanks but it didn't help with vdr 1.3.23, possibly my dish turning
motor is slow. I'll check if increasing time out values help!
Seppo
Seppo Ingalsuo wrote:
> Luca Olivetti wrote:
>
>>
>> As a stop-gag measure, while core vdr is properly adapted to steerable
>> dishes (Klaus, you promised it ;-), you can use the attached patch.
>> What it does is explained at
>> http://linuxtv.org/vdrwiki/index.php/Actuator-plugin#Patches
>>
> Thanks but it didn't help with vdr 1.3.23, possibly my dish turning
> motor is slow. I'll check if increasing time out values help!
Well, in spite of the name I'm using it with 1.3.23, and since it
doesn't wait for a lock the time is irrelevant. I'm sorry it doesn't
work for you but, as I said in the notes, YMMV :-(
Note that if you're using a ff card not in transfer mode, the patch
shouldn't make any difference, it's only useful with a budget card or if
the ff is using transfer mode (if I understood the logic of that piece
of code correctly).
Bye
Luca Olivetti wrote:
> Well, in spite of the name I'm using it with 1.3.23, and since it
> doesn't wait for a lock the time is irrelevant. I'm sorry it doesn't
> work for you but, as I said in the notes, YMMV :-(
Sorry, I was too inpatient. The picture pops to screen about 20-30s
after the positioner has stopped.
I wonder if I should try to hack diseqc.conf parsing to wait for some
time per each required degree for motor turn to avoid issuing the dvb
tuning command too early. In my system I don't get any feedback about
motor position. The worst case turn (28.2E to 1.0W) takes about 30s.
> Note that if you're using a ff card not in transfer mode, the patch
> shouldn't make any difference, it's only useful with a budget card or
> if the ff is using transfer mode (if I understood the logic of that
> piece of code correctly).
It is perfect for me because I'm using budget cards.
>
> Bye
>
>------------------------------------------------------------------------
>
>_______________________________________________
>vdr mailing list
>vdr@linuxtv.org
>http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
Seppo Ingalsuo wrote:
>
> I wonder if I should try to hack diseqc.conf parsing to wait for some
> time per each required degree for motor turn to avoid issuing the dvb
> tuning command too early.
That works well when combined with your patches! The hack also gives
possibility to drive motor close to final position with high LNB voltage
to get faster movement. I'm curious if the rotor plugin does similar
thing (not suitable for me because I'm using a legacy positioner)? As
far as I understand two way communication is supported in diseqc 2.0
while most diseqc positioners are only 1.2 so some kind of blind delay
for waiting motor is required.
Seppo
Seppo Ingalsuo wrote:
> Seppo Ingalsuo wrote:
>
>>
>> I wonder if I should try to hack diseqc.conf parsing to wait for some
>> time per each required degree for motor turn to avoid issuing the dvb
>> tuning command too early.
>
>
> That works well when combined with your patches! The hack also gives
> possibility to drive motor close to final position with high LNB voltage
> to get faster movement. I'm curious if the rotor plugin does similar
> thing (not suitable for me because I'm using a legacy positioner)? As
> far as I understand two way communication is supported in diseqc 2.0
> while most diseqc positioners are only 1.2 so some kind of blind delay
> for waiting motor is required.
I suppose. Since I'm using a "real legacy" ;-) positioner (no diseqc
involved at all), I know the position of the dish.
Bye
@@ -1057,10 +1057,12 @@
return false;
if (Receiver->device == this)
return true;
+ /*
if (!HasLock(TUNER_LOCK_TIMEOUT)) {
esyslog("ERROR: device %d has no lock, can't attach receiver!", CardIndex() + 1);
return false;
}
+ */
cMutexLock MutexLock(&mutexReceiver);
for (int i = 0; i < MAXRECEIVERS; i++) {
if (!receiver[i]) {
@@ -96,11 +96,14 @@
void cFileWriter::Action(void)
{
time_t t = time(NULL);
+ time_t m = MAXBROKENTIMEOUT * 10; //give more time to first packet
+
active = true;
while (active) {
int Count;
uchar *p = remux->Get(Count, &pictureType);
if (p) {
+ m = MAXBROKENTIMEOUT;
//XXX+ active??? see old version (Busy)
if (!active && pictureType == I_FRAME) // finish the recording before the next 'I' frame
break;
@@ -118,7 +121,7 @@
break;
t = time(NULL);
}
- else if (time(NULL) - t > MAXBROKENTIMEOUT) {
+ else if (time(NULL) - t > m) {
esyslog("ERROR: video data stream broken");
cThread::EmergencyExit(true);
t = time(NULL);