[vdr] Transfer mode and a motorised dish
malcolm.caldwell at ntu.edu.au
Tue Aug 9 07:30:47 CEST 2005
On Mon, 2005-08-08 at 10:56 +0200, Luca Olivetti wrote:
> En/na Malcolm Caldwell ha escrit:
> > Hello,
> > I get the feeling that 1.4 might be getting close - so I though I should
> > speak up now.
> > I have a request: find a way to fix transfer mode while using a
> > motorised dish.
> > I have a dxr3 based system and a motorized dish. The problem is vdr
> > only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it
> > reports "ERROR: device %d has no lock" and gives up.
> > This makes it fairly painful. I have to change channel, wait for the
> > dish to move and then go "menu->channels->OK" to re-tune the current
> > channel.
> > My "Fix" is not to return false after the timeout. This causes vdr to
> My fix is not to wait at all :-)
I tried that as well but I think this caused problems with my
> (unfortunately this breaks the ttxsubs plugin for recordings)
> > try to set up the filters anyway, and things work fine. When the dish
> > moves the channels just starts to work fine. (If I am not wrong, vdr
> > used to have no timeout here but some cards did not like you to set
> > filters when there was no lock... ?) Setting the timeout to a large
> > value is not an option as vdr is unresponsive during this period, making
> > channel surfing 'stick' at various places where channels are
> > un-available. I cannot think of a fix that preserves the "don't set
> > filters without a lock" behaviour without using another thread.
> > The other problem with vdr and motorised dishes is due to the timeout
> > for recordings. If vdr receives no data for MAXBROKENTIMEOUT defined in
> > recording.c it does an emergency restart. Now on the plus side, by the
> > time vdr restarts my dish has (so far) always moved to the correct
> > position! However, I must say it is hard to explain to my wife why the
> > recording we just happened to be watching at the time stopped midway
> > through...
> Here my fix is to wait ten time the MAXBROKENTIMEOUT but only for the
> first packet.
OK, this may be a good compromise.
> > Maybe some of this could be fixed by to rotor plugin, however the rotor
> > plugin should not be needed in this setup (I just define things in
> > diseqc.conf).
> There are other problems, like the channel autoupdate picking data from
> the wrong satellite. I don't think you can solve that without a plugin.
> In fact Klaus promised to check the plugins in the tuning thread to see
> if a channel can be actually tuned to and it is ready to be tuned. If he
> manages do to it and at the same time doesn't block vdr responsiveness
> to the remote I think it would be the best solution.
I am not sure that I completely understand this paragraph.
IMHO a plugin should not be needed, just some way to make sure that
'transient' data does not get added. Maybe a minimum time between
channel change and autoupdate? Again this could be configurable for
Changing source from C to T to S should not matter, but when changing
from SXXX to SYYY it does.
> However, Klaus kindly reminded us that his day has only 24 hours (bad,
> bad Klaus ;-), so you'll just have to be patient.
> vdr mailing list
> vdr at linuxtv.org
More information about the vdr