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).
