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 > > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
