En/na Jarmo Järvenpää ha escrit:

Dear list,

With Vdr 1.3.31

You mean 1.3.30?

and newest dxr3 -plugin there seems to be a problem when dvb-t card receives no signal at all. The screen is blank, but any remote control key presses cause no immediate effects.

This is because vdr is waiting for a lock, and it's not dxr3 specific (at least I suppose so).

Try commenting out the lines

if (!HasLock(TUNER_LOCK_TIMEOUT)) { esyslog("ERROR: device %d has no lock, can't attach receiver!", CardIndex() + 1); return false; }

in device.c

Bye

En/na Klaus Schmidinger ha escrit:

...

Try commenting out the lines

if (!HasLock(TUNER_LOCK_TIMEOUT)) { esyslog("ERROR: device %d has no lock, can't attach receiver!", CardIndex() + 1); return false; }

in device.c

Maybe I should drop this timeout altogether, because it seems like it's doing more bad than good...

I dropped it since you introduced it ;-) Dropping it altogether seems to do no harm for live-view but may cause problems for recordings and/or some plugins (e.g.the infamous ttxtsubtitles plugin) if there's no signal at once (like a signal problem or a steerable dish). I already proposed a possible solution

http://www.linuxtv.org/pipermail/vdr/2005-August/004179.html

but, as I said then, I'm not sure it's the correct one.

Bye

Klaus Schmidinger wrote:

You mean 1.3.30?

Indeed, I'm not sure where I got the .31 :-)

...

This is because vdr is waiting for a lock, and it's not dxr3 specific (at least I suppose so).

Try commenting out the lines

if (!HasLock(TUNER_LOCK_TIMEOUT)) { esyslog("ERROR: device %d has no lock, can't attach receiver!", CardIndex() + 1); return false; } in device.c

This cured the problem. Now turning off the antenna amplifier does no ill effects to responsiveness of vdr.

Thanks, Jarmo

On Sat, 2005-08-27 at 10:39 +0200, Luca Olivetti wrote:

Malcolm Caldwell wrote:

...

Again, IMHO, this seems fairly complex. Why should vdr consult plugins about this stuff?

e.g. because plain vdr doesn't know anything about a positioner (or other weird things: vdr is good because it's flexible and you can do almost everything you want with it).

Maybe. But why should vdr need a plugin to do normal diseqc 1.3 positioning? IMHO it should work 'out of the box'.

I guess this does not mean that there should not be a hook, just that its use should be optional and only an optimisation for positioners with plugins that can tell when the dish has finished moving. (actuator, and perhaps future diseqc positioners...)

...

I would have thought that vdr should be able to tell when a signal is valid etc.

Perhaps just having a time value indicating how long the signal had been locked would be enough. Then things like channel update etc. could just wait until there was (eg) 5 seconds of valid signal before it did anything.

That may be good for eit(?) scanning, not for attaching receivers: why wait 5 seconds when the dish is already positioned and you have a good signal?

I did not really mean that attaching receivers for live tv/transfer mode should wait. As I said, I think the drivers should 'just work' in this regard. Setting a filter should not be a problem even if there not currently a lock. But is this the case for all drivers? Perhaps we should ask on the linux-dvb list?

Waiting is needed for eit scanning, and perhaps other things, like recording, teletext etc.

Since I'm using a dxr3 (i.e. transfer mode i.e. a receiver) I wouldn't like to wait 5 seconds after each channel change.

True. I know the problem.

Bye

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

On Sun, 2005-08-28 at 10:34 +0300, Lauri Tischler wrote:

Malcolm Caldwell wrote:

...

Maybe. But why should vdr need a plugin to do normal diseqc 1.3 positioning? IMHO it should work 'out of the box'.

It does, depending how the dish position is reached. Diseqc commands are enough if you use only those positions which are preprogrammed into the motor.

No - it does not work if moving the dish will take more time than the timeout.

My dish can take over 90 seconds to move. I do use diseqc commands to move to a new stored position, and that part works fine. The problem is that by the time the dish gets to its new position the transfer mode has timed out, and I have to 're-select' the channel to see anything.

There is also a problem with recordings. VDR's recording thread times out and does an emergency restart of vdr when it moves the dish to start a recording. Quite annoying if you are watching something at the time!

If you use command like 'gotoxy 28.2E' you need to do a bunch of trigonometric calculations not found in basic VDR. Read the source, gotoxy-patch in Rotor-plugin.

I have. My dish positioner is diseqc 1.2 only so it is not relevant.

(I have a big C-band dish, a 'jack' and v-box II Positioner)

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

malcolm.caldwell@ntu.edu.au(Malcolm Caldwell) 28.08.05 14:37

On Sat, 2005-08-27 at 10:39 +0200, Luca Olivetti wrote:

...

Malcolm Caldwell wrote:

...

Again, IMHO, this seems fairly complex. Why should vdr consult plugins about this stuff?

e.g. because plain vdr doesn't know anything about a positioner (or other weird things: vdr is good because it's flexible and you can do almost everything you want with it).

Maybe. But why should vdr need a plugin to do normal diseqc 1.3 positioning? IMHO it should work 'out of the box'.

I guess this does not mean that there should not be a hook, just that its use should be optional and only an optimisation for positioners with plugins that can tell when the dish has finished moving. (actuator, and perhaps future diseqc positioners...)

Please don't forget the similar "resource dependency" problems, "LNB-sharing" users have on the other (lower) end.

Dish positioned to satellite A should never be moved to B, if a timer is running.

That' pretty the same with LNB sharing: If polarization is currently "vertical" and a timer is running, it should never switch to "horizontal", because that would break the running recording. But it's no problem to switch to an other "vert" channel, on an other board.

The current Solution VDR offers offers is: Buy a dish for each satellitte. At least if the responses acording to LNB-sharing will be translated to motor dishes.

That's a : "A software with a hardware patch"! ;-)

When VDR was new, everybody was happy it works, Nobody cares about CAM, sharing LNB, Diseq, motor dishes and cards with different channels (multi dish).

Maybe the entire resource handling should rewritten from scratch, systematcally?

Rainer