Commit Message
Lauri Tischler wrote:
> Well known problem is that when rotating the dish, it picks
> up bogus channels.
> Any news in this aspect ?
> One solution would be to just calculate the distance between
> old and new position and just wait one second per degree
> or whatever is the speed of your rotor.
In the actuator plugin, since I know the position of the dish, if it
isn't positioned on the target satellite I set Setup.UpdateChannels to 0.
I also patch vdr *not* to wait for a lock, and give it more time before
deciding that there's no data coming for a recording (see attached patch).
Unfortunately both of these solutions aren't the best option: since vdr
looks for SI data (?) only right after switching channel, setting
Setup.UpdateChannels to 0 will prevent channel updates until a new
channel is selected on the same satellite, and not waiting for a lock,
while not really problematic for live view, for a recording could give
problems (e.g. with the teletext subtitles plugin).
Klaus promised a better solution a while ago, I'm still waiting ;-)
Bye
Comments
On Fri, 2005-07-22 at 16:33 +0200, Luca Olivetti wrote:
> Lauri Tischler wrote:
> > Well known problem is that when rotating the dish, it picks
> > up bogus channels.
> > Any news in this aspect ?
> > One solution would be to just calculate the distance between
> > old and new position and just wait one second per degree
> > or whatever is the speed of your rotor.
>
> In the actuator plugin, since I know the position of the dish, if it
> isn't positioned on the target satellite I set Setup.UpdateChannels to 0.
> I also patch vdr *not* to wait for a lock, and give it more time before
> deciding that there's no data coming for a recording (see attached patch).
> Unfortunately both of these solutions aren't the best option: since vdr
> looks for SI data (?) only right after switching channel, setting
> Setup.UpdateChannels to 0 will prevent channel updates until a new
> channel is selected on the same satellite, and not waiting for a lock,
> while not really problematic for live view, for a recording could give
> problems (e.g. with the teletext subtitles plugin).
> Klaus promised a better solution a while ago, I'm still waiting ;-)
Just to second this:
Without such a patch vdr does not work very well with a dish positioner.
(At least with my dxr3. I don't know about a FF card, it might work for
replay, but the timeout for recordings would still be too low)
Its hard to explain to my wife why vdr must restart while we are
watching a recording because it is recording something of a more distant
satellite.
> Bye
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
@@ -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);