[vdr] Transfer mode and a motorised dish

Malcolm Caldwell malcolm.caldwell at ntu.edu.au
Mon Aug 15 02:55:37 CEST 2005


On Tue, 2005-08-09 at 15:00 +0930, Malcolm Caldwell wrote:
> 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
> Terrestrial card.
> 
> > (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.
> 
> 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.
> > 
> > Bye

Klaus: do you have any thoughts on this subject.  IMHO current vdr is
broken for movable dishes.

(While it may work a bit for live tv on a ff card, recordings require a
restart to work and transfer mode does not work either).






More information about the vdr mailing list